SWAMINARAYAN SIDDHANTA INSTITUTE OF TECHNOLOGY, NAGPUR

COMPUTER ENGINEERING DEPARTMENT

Session: 2025-2026
Semester: B.Tech 5th SEM (Third Year)
Subject: Software Engineering Lab

Student Name :……………………………….

Roll. No. :……………………………….
Enrollment No :……………………………….
Practical Incharge :………………………………
SWAMINARAYANA SIDDHANTA INSTITUTE OF TECHNOLOGY, NAGPUR

CERTIFICATE

This is certified that Mr. / Ms. / Mrs. student of

B.Tech. semester has satisfactorily completed no. of Experiments in the subject

during the academic year 2023-2024.

His / Her conduct and attendance inside the laboratory was satisfactory / not satisfactory.

Date:

Signature of Teacher Signature of H.O.D.

 INDEX

List of Experiment Page Date Sign Marks

Sr. No.
No.
To perform the system analysis: Requirement Analysis
and develop the Software Requirement Specification
(SRS) including both Functional and Non-Functional
1. requirements for different sample problems.

To perform the function-oriented diagram

2. representation using Data Flow Diagram (DFD) and
Structured Chart.

To perform the user’s view analysis of a system

3. using Use Case Diagrams

To draw the structural view diagrams: Class Diagram

4. and Object Diagram for different sample problems.

To draw the behavioral view of a system using

5. Sequence Diagrams and Collaboration Diagrams

To draw the behavioral view of a system using State-

6. chart Diagrams and Activity Diagrams.

Date: Signature of Teacher:

 Practical No. 1
Aim: To perform the system analysis: Requirement Analysis and develop the Software Requirement
Specification (SRS) including both Functional and Non-Functional requirements for different sample
problems.

Theory:
System Analysis is the process of understanding and specifying what a system should do.
- Requirement Analysis identifies user needs.
- Functional Requirements (FRs): Describe what the system must do.
- Non-Functional Requirements (NFRs): Define system quality attributes (performance, reliability, usability, etc.).
- Software Requirement Specification (SRS): A formal document containing all requirements.

Problem 1: Library Management System

Requirement Analysis:
The system handles the main functions related to library management system.
 Functional Requirements:

1. Maintain records of books and members

2. Allow members to issue and return books
3. Generate reports of overdue books

 Non-Functional Requirements:

4. System should be available 24x7

5. Average response time < 2 sec

Problem 2: Online Railway Reservation System

Requirement Analysis:
The system handles the main functions related to online railway reservation system.
 Functional Requirements:

6. Search trains by route/date

7. Book and cancel tickets
8. Provide online payment gateway

 Non-Functional Requirements:

9. System should handle 10,000 concurrent users

10. Payment must be secure (SSL encryption)

Problem 3: Hospital Management System

Requirement Analysis:
The system handles the main functions related to hospital management system.
 Functional Requirements:

11. Register patients and doctors

12. Schedule/cancel appointments
13. Generate bills and medical history

 Non-Functional Requirements:

14. Data privacy as per medical regulations

15. System downtime < 1 hr per month

Problem 4: Payroll Management System

Requirement Analysis:
The system handles the main functions related to payroll management system.
 Functional Requirements:

16. Maintain employee records

17. Calculate salary, deductions, and taxes
18. Generate pay slips

 Non-Functional Requirements:

19. Accuracy of salary computation must be 100%

20. Reports should be generated within 5 sec

Problem 5: Online Banking System

Requirement Analysis:
The system handles the main functions related to online banking system.
 Functional Requirements:

21. View account balance and transactions

22. Transfer funds between accounts
23. Pay bills online

 Non-Functional Requirements:

24. Security with OTP verification

25. Availability: 99.99% uptime

Problem 6: Inventory Management System

Requirement Analysis:
The system handles the main functions related to inventory management system.
 Functional Requirements:

26. Maintain stock records

27. Generate purchase and sales reports
28. Alert for low stock

 Non-Functional Requirements:

29. Response time < 3 sec

30. Data backup every 24 hours

Problem 7: Student Information System

Requirement Analysis:
The system handles the main functions related to student information system.
 Functional Requirements:

31. Store student personal and academic details

32. Record attendance and grades
33. Generate progress reports

 Non-Functional Requirements:

34. Easy-to-use UI for faculty

35. Must support at least 5000 students

Problem 8: ATM System

Requirement Analysis:
The system handles the main functions related to atm system.
 Functional Requirements:

36. Authenticate user with card + PIN

37. Withdraw/deposit cash
38. Print mini statement

 Non-Functional Requirements:

39. Transaction response < 10 sec

40. System must be fault-tolerant

Problem 9: E-Commerce Website

Requirement Analysis:
The system handles the main functions related to e-commerce website.
 Functional Requirements:

41. Browse and search products

42. Add/remove items from cart
43. Make secure online payments

 Non-Functional Requirements:

44. Must support 1 lakh users simultaneously

45. Website load time
Problem 10: Examination Management System
Requirement Analysis:
The system handles the main functions related to examination management system.
 Functional Requirements:

46. Create and manage question papers

47. Allow students to take exams online
48. Auto-evaluate objective answers

 Non-Functional Requirements:

49. Prevent cheating (randomized questions)

50. Results must be available instantly

Conclusion:
Requirement analysis helps in understanding the customer’s needs clearly. SRS provides a structured document including
both functional and non-functional requirements, which becomes the foundation for design and implementation.
 8
Practical No. 02

Aim: To perform the function-oriented diagram representation using Data Flow Diagram (DFD) and
Structured Chart.

Theory:
 Data Flow Diagram (DFD):
o Represents the flow of data in a system.
o Shows processes, data stores, external entities, and data flows.
o Levels:
 Level 0 (Context Diagram): Overall system as a single process.
 Level 1: Breaks the system into major processes.
 Level 2: Further decomposes processes.
 Structured Chart:
o A hierarchical chart representing the breakdown of a system’s modules.
o Shows how functions of the system are organized and related.
o Helps in modular design and program structure.

Example 1: Library Management System

DFD – Level 0 (Context Diagram):
[Student] ---> (Library System) ---> [Librarian]
DFD – Level 1:
(Student) ---> (Search Book) ---> (Book Database)
(Student) ---> (Issue Book) ---> (Book Database)
(Librarian) ---> (Update Records) ---> (Book Database)

Structured Chart:
+---------------------+
| Library System |
+---------------------+
/ | \
/ | \
Search Book Issue Book Update Records
 9
Example 2: Online Railway Reservation System
DFD – Level 0 (Context Diagram):
[Passenger] ---> (Reservation System) ---> [Railway Database]
DFD – Level 1:
(Passenger) ---> (Search Train) ---> (Train Database)
(Passenger) ---> (Book Ticket) ---> (Payment Gateway)
(Passenger) ---> (Cancel Ticket) ---> (Reservation Records)

Structured Chart:
+-----------------------------+
| Railway Reservation System |
+-----------------------------+
/ | \
/ | \
Search Train Book Ticket Cancel Ticket
|
Payment Gateway

Conclusion:
 DFD helps to understand the flow of data in the system.
 Structured Chart helps to understand the functional decomposition of the system.
 Both are useful tools in function-oriented design and system analysis.
 10
Practical No. 03

Aim: To perform the user’s view analysis of a system using Use Case Diagrams.
Theory:
 Use Case Diagram:
o A UML diagram used to represent the functional requirements of a system.
o Shows the interaction between actors (users/external systems) and use cases (system
functionalities).
o Helps in understanding what the system should do from the user’s perspective.

Components:

 Actors: External entities that interact with the system (e.g., user, admin, external system).
 Use Cases: Functionalities provided by the system.
 System Boundary: Defines the scope of the system.
 Relationships: Includes association, include, extend, and generalization.

Example 1: Library Management System

Actors:
 Student
 Librarian

Use Cases:
 Search Book
 Issue Book
 Return Book
 Update Records

Diagram (Text Form):

+-----------------------------+
| Library System |
| |
Student -->| (Search Book) |
Student -->| (Issue Book) |
Student -->| (Return Book) |
Librarian->| (Update Records) |
+-----------------------------+
 11
Example 2: Online Railway Reservation System
Actors:
 Passenger
 Admin

Use Cases:
 Search Train
 Book Ticket
 Cancel Ticket
 Generate Reports

Diagram (Text Form):

+---------------------------------------+
| Railway Reservation System |
| |
Passenger->| (Search Train) |
Passenger->| (Book Ticket) |
Passenger->| (Cancel Ticket) |
Admin ---->| (Generate Reports) |
+---------------------------------------+

Example 3: Online Shopping System

Actors:
 Customer
 Admin

Use Cases:
 Browse Products
 Add to Cart
 Make Payment
 Manage Inventory

Diagram (Text Form):

+----------------------------------+
| Online Shopping System |
| |
Customer ->| (Browse Products) |
Customer ->| (Add to Cart) |
Customer ->| (Make Payment) |
Admin ---->| (Manage Inventory) |
+----------------------------------+
 12

Conclusion:
 Use Case Diagram provides a clear picture of system functionality from the user’s perspective.
 It is an effective tool for requirement analysis and helps in communication between stakeholders and
developers.
 13

Practical No.04
Aim: To draw the structural view diagrams: Class Diagram and Object Diagram for
different sample problems.

Theory:
 Class Diagram:
Represents the static structure of the system, showing classes, their attributes, methods, and
relationships.
 Object Diagram:
Shows instances of classes (objects) and links between them at a particular point in time.

Class diagram = blueprint of the system.

Object diagram = snapshot of system state.

Example 1: Library Management System

Class Diagram:
Classes:

 Book (bookID, title, author, availability; addBook(), issueBook(), returnBook())

 Member (memberID, name, contact; register(), requestBook())
 Librarian (staffID, name; manageBooks(), generateReport())
 Transaction (transactionID, issueDate, returnDate; createTxn(), closeTxn())

Diagram (Class Diagram):

+----------------+ +----------------+
| Book |<>------->| Transaction |
+----------------+ +----------------+
| bookID | | transactionID |
| title | | issueDate |
| author | | returnDate |
+----------------+ +----------------+
| addBook() | | createTxn() |
| issueBook() | | closeTxn() |
| returnBook() | +----------------+
+----------------+
^
|
+----------------+ +----------------+
| Member | | Librarian |
+----------------+ +----------------+
| memberID | | staffID |
| name | | name |
+----------------+ +----------------+
| register() | | manageBooks() |
| requestBook() | | generateReport()|
+----------------+ +----------------+
 14
Object Diagram:
Objects:

 b1 : Book (bookID=101, title="DBMS")

 m1 : Member (memberID=501, name="Raj")
 l1 : Librarian (staffID=10, name="Anita")
 t1 : Transaction (txnID=9001, issueDate="24-08-2025")

Diagram (Object Diagram):

+----------------+ +----------------+
| b1 : Book |------->| t1 : Transaction|
| "DBMS" | | txnID=9001 |
+----------------+ +----------------+

+----------------+ +----------------+
| m1 : Member | | l1 : Librarian |
| Raj | | Anita |
+----------------+ +----------------+

Example 2: Online Railway Reservation System

Class Diagram:
 Train (trainNo, source, destination; searchTrain())
 Passenger (passengerID, name; login(), bookTicket())
 Ticket (pnrNo, status; generateTicket(), cancelTicket())
 Payment (amount, mode; makePayment())

Object Diagram:
 train101 : Train (Delhi–Mumbai)
 p1 : Passenger (Ravi)
 t1 : Ticket (PNR=889922, status="Booked")
 pay1 : Payment (amount=1500, mode="UPI")

Conclusion: Structural diagrams provide a static view of the system.

 Class diagrams show the design blueprint.
 Object diagrams show real-time instances of classes.
Together, they help in system design and documentation.
 Practical No.05 15

Aim: To draw the behavioral view of a system using Sequence Diagrams and Collaboration Diagrams.

Theory:
 Behavioral View:
Describes the dynamic behavior of a system – how objects interact over time.

1. Sequence Diagram:
 Represents the interaction between objects arranged in a time sequence.
 Focuses on “when” messages are sent and in what order.
 Elements:
o Objects
o Lifelines
o Messages (synchronous/asynchronous)
o Activation bars

2. Collaboration Diagram (Communication Diagram):

 Represents interactions between objects but focuses on the structural organization of objects.
 Shows “which objects” interact and how.
 Elements:
o Objects (nodes)
o Links between objects
o Numbered messages (to show order)

Example 1: Library Management System

Actors & Objects:
 Actor: Student
 Objects: Library System, Book Database

Sequence Diagram:
1. Student → Search Book
2. System → Query Book Database
3. Database → Return Book Details
4. System → Display Result

Student → Library System → Book Database

| | |
|---Search---> | |
| |---Query---------> |
| |<--Book Details--- |
|<--Results--- | |
 16
Collaboration Diagram:
 Student sends Search Book request to Library System.
 Library System queries Book Database.
 Book Database returns details.

[Student] ---1: Search Book---> [Library System] ---2: Query---> [Book Database]
[Book Database] ---3: Book Details---> [Library System] ---4: Result---> [Student]

Example 2: Online Shopping System

Actors & Objects:
 Actor: Customer
 Objects: Shopping System, Payment Gateway

Sequence Diagram:
1. Customer → Browse Products
2. Customer → Add to Cart
3. Customer → Make Payment
4. System → Payment Gateway → Confirm Payment

Customer → Shopping System → Payment Gateway

| | |
|--Browse--> | |
|--Add Cart->| |
|--Pay------>|---Request-------> |
| |<--Confirmation--- |
|<--Receipt--| |

Collaboration Diagram:
 Customer browses products (1)
 Adds to cart (2)
 Makes payment (3)
 System communicates with Payment Gateway (4)
 Confirmation sent back (5)

[Customer] --1: Browse--> [Shopping System]

[Customer] --2: Add Cart-> [Shopping System]
[Customer] --3: Pay------> [Shopping System] --4: Request--> [Payment Gateway]
[Payment Gateway] --5: Confirmation--> [Shopping System] --6: Receipt--> [Customer]

Conclusion:
 Sequence Diagram emphasizes the time order of messages.
 Collaboration Diagram emphasizes the structural relationship among objects.
 Both are essential to understand dynamic behavior of the system.
 17

Practical No.06

Aim : To draw the behavioral view of a system using State-chart Diagrams and
Activity Diagrams.

Theory:
1. State-chart Diagram (State Machine Diagram):
 Represents the different states of an object and the transitions between those states.
 Useful for modeling reactive systems where state changes are triggered by events.
 Key Elements:
o States (Start, Intermediate, Final)
o Transitions (arrows)
o Events/Conditions

2. Activity Diagram:
 Represents the workflow of activities in a system.
 Shows how processes/activities are carried out step by step.
 Key Elements:
o Initial Node (Start)
o Activities (rounded rectangles)
o Decisions/Merges (diamonds)
o Final Node (End)

Example 1: Library Management System

State-chart Diagram:
States of a Book object:

 Available → Issued → Returned → Available

[Available] --Issue--> [Issued] --Return--> [Available]

Activity Diagram:
Steps for Borrowing a Book:

1. Start
2. Search Book
3. Check Availability
o If Available → Issue Book
o If Not Available → Display "Not Available"
4. End
 18
(Start) → (Search Book) → (Check Availability)?
├── Yes → (Issue Book) → (End)
└── No → (Not Available) → (End)

Example 2: Online Shopping System

State-chart Diagram:
States of an Order:

 Created → Paid → Shipped → Delivered

[Created] --Payment Done--> [Paid] --Dispatch--> [Shipped] --Delivered--> [Completed]

Activity Diagram:
Steps for Placing an Order:

1. Start
2. Browse Products
3. Add to Cart
4. Make Payment
5. Confirm Order
6. End

(Start) → (Browse Products) → (Add to Cart) → (Make Payment) → (Confirm Order) → (End)

Conclusion:
 State-chart diagrams help in understanding how objects change states based on events.
 Activity diagrams represent the workflow and control flow of processes.
 Both are essential for modeling the dynamic behavior of systems.