0% found this document useful (0 votes)
2 views4 pages

Software Engineering Lab Experiments

The document outlines five software engineering experiments, each with specific objectives and detailed descriptions. Experiment 1 focuses on creating a Software Requirement Specification for a Library Management System, while Experiment 2 involves developing a Use Case Diagram for an Online Shopping System. The remaining experiments include preparing Data Flow Diagrams, a Sequence Diagram for e-commerce transactions, and an Entity-Relationship Diagram for an Employee Management System.

Uploaded by

arsecist
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views4 pages

Software Engineering Lab Experiments

The document outlines five software engineering experiments, each with specific objectives and detailed descriptions. Experiment 1 focuses on creating a Software Requirement Specification for a Library Management System, while Experiment 2 involves developing a Use Case Diagram for an Online Shopping System. The remaining experiments include preparing Data Flow Diagrams, a Sequence Diagram for e-commerce transactions, and an Entity-Relationship Diagram for an Employee Management System.

Uploaded by

arsecist
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Here is the expanded content for each of the five experiments, formatted specifically to meet

the requirements of a formal Software Engineering Lab (BCS651) file following the AKTU
syllabus.

Experiment 1

Objective: Prepare a Software Requirement Specification (SRS) using IEEE Standards for a
Library Management System.

1. Introduction
●​ Purpose: This document provides a detailed description of the Library Management
System (LMS). It is intended for developers, testers, and project managers.​

●​ Scope: The system will handle the tracking of books, member registrations, and the
processing of issued/returned materials to replace manual ledgers.​

2. Overall Description
●​ Product Perspective: The LMS is a standalone system with a back-end database and a
front-end user interface.​

●​ User Classes and Characteristics:


○​ Admin: Responsible for system maintenance and user account management.​

○​ Librarian: Handles the core operations like adding books and processing loans.​

○​ Students/Members: Can search for books and view their own account history.​

3. System Requirements
●​ Functional Requirements:
○​ Registration: The system must allow new members to register and create profiles.​

○​ Search: Users must be able to search for books by title, author, or ISBN.​

○​ Fine Management: The system must automatically calculate fines for overdue
books.​
●​ Non-Functional Requirements:
○​ Reliability: The system should be available 99.9% of the time during library hours.​

○​ Usability: The interface should be intuitive enough for users with basic computer
knowledge.​

Experiment 2

Objective: To create a Use Case Diagram for the Online Shopping System showing interactions
between customers, administrators, and payment systems.

1. Identification of Actors
●​ Customer: The primary user who browses and buys products.​

●​ Administrator: The user responsible for updating product listings and managing
inventory.​

●​ Payment System: An external entity that validates credit card or UPI transactions.​

2. Use Case Descriptions


●​ Product Browsing: Customer views various categories and product details.​

●​ Order Placement: Customer adds items to a cart and confirms the purchase.​

●​ Payment Processing: The system interacts with the Payment Gateway to authorize the
transaction.​

●​ Order Tracking: Customer checks the shipping status of their purchased items.​

Experiment 3

Objective: Prepare Data Flow Diagrams (DFD) at Level 0, Level 1, and Level 2 for the Library
Management System.

1. Level 0 (Context Diagram)


●​ Shows the entire LMS as a single process.​

●​ Inputs: Book details from Librarian; Membership details from Student.​

●​ Outputs: Receipt/Book to Student; Inventory reports to Librarian.​

2. Level 1 (Functional Decomposition)


●​ Breaks down the system into core sub-processes: User Management, Book
Management, and Transaction Management.​

●​ Data flows between these processes and data stores like "Book DB" and "Member DB".​

3. Level 2 (Detailed DFD)


●​ Expands the Transaction Management process into specific sub-processes like Check
Availability, Update Record, and Calculate Late Fee.​

Experiment 4

Objective: Prepare a Sequence Diagram illustrating the product purchase process in an online
e-commerce system.

1. Participants (Lifelines)
●​ Customer: Initiates the purchase.​

●​ System/Web Interface: The intermediary handling user requests.​

●​ Payment Service: External service for financial validation.​

●​ Database: Stores order and inventory details.​


2. Sequence of Events
1.​ Select Product: Customer sends a request to the System to add an item to the cart.​

2.​ Checkout: Customer initiates the checkout process.​

3.​ Validate Payment: System sends payment details to the Payment Service.​

4.​ Confirm Payment: Payment Service sends a "Success" or "Failure" message back.​

5.​ Update Inventory: Upon success, the System updates the Database and sends a
confirmation to the Customer.​

Experiment 5

Objective: Prepare an Entity–Relationship (ER) Diagram for an Employee Management System.

1. Entities and Attributes


●​ Employee: Contains attributes like Emp_ID (Primary Key), Name, Role, and Salary.​

●​ Department: Contains Dept_ID (Primary Key) and Dept_Name.​

●​ Project: Contains Proj_ID, Proj_Title, and Deadline.​

2. Relationships
●​ Works In: An Employee works in one Department, while a Department has many
Employees (1:N relationship).​

●​ Manages: An Employee (Manager) manages a Department (1:1 relationship).​

●​ Assigned To: Employees are assigned to various Projects (M:N relationship, as one
employee can have multiple projects and vice versa).​

You might also like