DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

LAB MANUAL
Academic Year: 2026-27 ODD SEMESTER

Programme (UG/PG) : UG
Semester :5
Course Code : 24CS5504
Course Title : SOFTWARE DEVELOPMENT LAB

Lab Manual/CSE

i
 LIST OF EXPERIMENTS & SCHEDULE

Course Code: 24CS5504

Course Title: SOFTWARE DEVELOPMENT LAB

Exp. No. Title Week No.

1. Student Course Registration 1&2

2. Payroll processing application 3&4

3. Automated banking system 5&6

4. Library Management System 7&8

5. Railway Reservation system 9 & 10

6. Trading system 11 & 12

7. Cellular phone system 13& 14

Course Coordinator HoD

Lab Manual/CSE

ii
 HARDWARE AND SOFTWARE REQUIREMENTS

Hardware Requirements:

Software Requirements:

Lab Manual/CSE

iii
EX NO : 1
Date :
STUDENT COURSE REGISTRATION

1.0 PROBLEM DEFINITION

To build software that automates the student’s course registration.
1.1 This is proposed for automating the student’s course registration. While the student joins
any educational institution his admission is made on the basis of his previous records.
1.2 The students who wish to the institution must be given with the available course details.
1.3 The student is allotted with a seat in the institution based on the marks that he scored in
the institution he studied previously. After the confirmation of his joining the student must
be given with new identity and records as per the institution.
2.0 SYSTEM REQUIREMENT SPECIFICATION
2.1 THE OVERALL DESCRIPTION
2.1.1 This is proposed for automating the student’s course registration. While the student
joins any educational institution his admission is made on the basis of his previous
records.
2.1.2 The students who wish to the institution must be given with the available course
details.
2.2 PRODUCT PERSPECTIVE
2.2.1 Hardware interfaces
Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system
running on high rpm hard disk permitting complete data redundancy and
back-up systems to support the primary goal of reliability.
The system must interface with the standard output device, keyboard
and mouse to interact with this software.
2.2.2 Software interfaces
Back End: MS-Access
Front End: Microsoft Visual Basic 6.0
2.2.3 Memory Constraints

<24CS5504/SD lab> Lab Manual/CSE

1
 [Link].1 No specific constraints on memory.
2.3 FRONT – END DESCRIPTION
The Student Course registration system is automated system where the user can register the
student for various courses.
2.4 BACK – END DESCRIPTION
The Student Course registration system consists of two tables. One contains the student
details such as the name, id number that is the password, address, and date of birth. The Course
details consist of the title of the course, code of the course, available seats.

2.5 DATA FLOW DIAGRAM:

Student

Payment

Fees Receipt
Course

Balance DO Pay

Fees Pay Enquiries

<24CS5504/SD lab> Lab Manual/CSE

2
3.0 TESTING:
FORM NAME INPUT EXPECTED ACTUAL STATUS
OUTPUT OUTPUT
MAIN FORM Details Details are Details are Pass
displayed displayed
REGISTRATION Enter the Check Seats Pass
FORM student of Availability
details
REPORT FORM Select Course Display the Students Pass
particular details are
course student displayed

4.0 SAMPLE FORMS

<24CS5504/SD lab> Lab Manual/CSE

3
<24CS5504/SD lab> Lab Manual/CSE

4
5.0 RESULT:
Thus the online student course registration System was implemented using the specified front end
and back end tools.

<24CS5504/SD lab> Lab Manual/CSE

5
EX NO :2
Date :
PAYROLL PROCESSING APPLICATION

1.0 PROBLEM DEFENITION

A payroll application is to be developed which is required to perform the following functions:
1.1 It must provide a user in employee mode with the details of an employee, which includes
his name, department, date of joining and salary.
1.2 It must validate an user to enter in administrator mode using password. It must provide a
user to enter in administrator mode to view or modify an employee’s details using his
employee ID. It must also allow the user to add a new employee and generate the payroll.

2.0 SRS DOCUMENT PAYROLL PROCESSING APPLICATION

2.1 INTRODUCTION
2.1.1 Purpose
[Link] The purpose of this SRS is to describe the requirements involved in
developing a Payroll Processing System. (PPA).
[Link] The intended audience is any person who wants
[Link].1 To check employee details (both employee and administrator
mode).
[Link].2 To add new employee, modify any employee’s details or generate
payroll for the employee (only administer mode).
2.1.2 Scope
[Link] The product is titled Payroll Processing Application.
[Link] The product will perform the following tasks
[Link].1 Allow either an employee or an administrator to view employee details.
[Link].2 Allow the administrator to add a new employee with corresponding details.
[Link].3 Allow the administrator to modify the detail of an employee.
[Link].4 Allow the administrator to generate the payroll for the employee.

<24CS5504/SD lab> Lab Manual/CSE

6
2.1.3 Definitions, Acronyms and Abbreviations
[Link] PPA: Payroll Processing System.
2.1.4 References
[Link] IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
[Link] The SRS contains an analysis of the requirements necessary to help easy design.
[Link] The overall description provides interface requirements for the Payroll Processing
System, product perspective, hardware interfaces, software interfaces,
communication interface, memory constraints, product functions, user
characteristics and other constraints.
[Link] Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect Payroll
Processing System in any fashion.
2.2 THE OVERALL DESCRIPTION
2.2.1 Product perspective
[Link] Hardware interfaces
[Link].1 Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system (such
as any RDBMS) running on high rpm hard-disk permitting complete data
redundancy and back-up systems to support the primary goal of reliability.
[Link].2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
[Link] Software interfaces
[Link].1 Back End: Oracle
[Link].2 Front End: Microsoft Visual Basic 6.0
[Link] Memory Constraints
[Link].1 No specific constraints on memory.
[Link] Operations
[Link].1 The software allows two modes of operations

<24CS5504/SD lab> Lab Manual/CSE

7
 [Link].1.1 The administrator mode allows user to add a new employee, modify
the existing details of an employee, generate payroll and also view
the details of an employee.
2.2.2 Product Functions
[Link] Viewing the employee details
The user (both administrator and employee) must have the access to Up-to-date
information about the employee including
[Link].1 Employee Id
[Link].2 Employee Name
[Link].3 Employee Department
[Link].4 Date of Joining
[Link].5 Salary
[Link] Adding a new employee
The user (only in administrator mode) must be able to add a new employee by supplying
the following employee details.
[Link].1 Employee Name
[Link].2 Employee Department
[Link].3 Date of Joining
[Link].4 Salary
[Link] Modifying the details of an employee
The user (only in administrator mode) must be able to modify the following details of an
existing employee.
[Link].1 Employee Name
[Link].2 Employee Department
[Link].3 Date of Joining
[Link].4 Salary
2.2.3 User characteristics
[Link] The intended users of this software need not have specific knowledge as to what is
the internal operation of the system. Thus the end user is at a high level of
abstraction that allows easier, faster operation and reduces the knowledge
requirement of end user

<24CS5504/SD lab> Lab Manual/CSE

8
 [Link] The Product is absolutely user friendly, so the intended users can be the naïve
users.
[Link] The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use this
product.
2.2.4 Constraints
[Link] At the time of adding a new employee, each employee must be assigned a unique
ID number.
2.3 SPECIFIC REQIREMENTS
2.3.1 Logical Database Requirements
[Link] There is only one database which contains all the necessary information about an
employee which includes employee ID, employee name, department, date if joining and
salary.
2.4 FRONT – END DESCRIPTION
The front end for the Payroll Processing Application (PPA) is designed using Microsoft
Visual Basic 6.0. The front – end contains a user – friendly interface. It has a welcome screen that
provides an option for the user to enter in employee mode or in administrator mode. In employee
mode the user can enter the employee ID of the employee and view his details. The user has to
validate him self using password to enter in administrator mode. In administrator mode, apart form
viewing the details the user can also ass a new employee by providing details or modify the existing
details using the employee ID.

2.5 BACK – END DESCRIPTION

There is only one table. It correlates a unique employee ID with his name, department, date of
joining and salary.

<24CS5504/SD lab> Lab Manual/CSE

9
2.6 A FLOW DIAGRAM

Display
Employe
e

User Check
accesibiltr
Retriev
e

Add Pay
new slip Display
Modify report
records

Employee
Delete data
records Gather
details

Compute
Confirm net
details Updat
e

<24CS5504/SD lab> Lab Manual/CSE

10
3.0 TESTING

FORM NAME INPUT EXPECTED ACTUAL STATUS

OUTPUT OUTPUT
Form 1 Add employee Add employee Add employee Pass
page displayed page displayed
Form 2 Employee Add new New employee Pass
details employee added
Form 3 Employee ID Modify Employee Pass
employee details modified
details
Form 4 Employee ID an Computed Salary Pass
basic pay salary computed and
displayed

4.0 SAMPLE FORMS

<24CS5504/SD lab> Lab Manual/CSE

11
<24CS5504/SD lab> Lab Manual/CSE

12
<24CS5504/SD lab> Lab Manual/CSE

13
5.0 RESULT
Thus the Payroll System was implemented using the specified front end and back end tools.

<24CS5504/SD lab> Lab Manual/CSE

14
EX NO :3
Date :
AUTOMATED BANKING SYSTEM

1.0 PROBLEM DEFENITION

To develop an automated banking system, which is required to perform the following functions:
1.1 The customer logs into the system using card number and pin number. The system checks
for validation.
1.2 The system queries the customer for the type of account either fixed deposit or credit
account. After getting the type of account the system shows the balance left.
1.3 The system queries the customer for the transaction type either withdrawal or deposit and
the required amount. The user enters the amount and the transaction if carries out
2.0 SRS DOCUMENT FOR AUTOMATED BANKING SYSTEM
2.1 INTRODUCTION
2.1.1 Purpose
[Link] The purpose of this SRS is to describe the requirements involved in
developing an Automated Banding System (ABS).
[Link] The intended audience is any person who wants
[Link].1 To create account.
[Link].2 To withdraw or deposit either in fixed deposit or credit account.
2.1.2 Scope
[Link] The product is titled Automated Banking System (ABS).
[Link] The product will perform the following tasks
[Link].1 Allow a new user to create an account, either fixed or credit account by
entering the details and by depositing an initial amount.
[Link].2 Allow the existing user to enter his account details like card number, pin
number and account type to view his balance.
[Link].3 Allow the existing user to deposit an amount by entering the amount to be
deposited after the balance had been viewed.

<24CS5504/SD lab> Lab Manual/CSE

15
 [Link].4 Allow the existing user to withdraw an amount by entering the amount to be
withdrawn after the balance had been viewed.
[Link].5 The primary benefits expected of the system are: user friendly, continuous
connectivity without failure, fault tolerant and involves lesser manpower.
2.1.3 Definitions, Acronyms and Abbreviations
[Link] ABS: Automated Banking System.
2.1.4 References
[Link] IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
[Link] IEEE Software Requirements Specifications Template
[Link]
srs_template.doc
2.1.5 Overview
[Link] The SRS contains an analysis of the requirements necessary to help easy design.
[Link] The overall description provides interface requirements for the Banking system,
product perspective, hardware interfaces, software interfaces, communication
interface, memory constraints, product functions, user characteristics and other
constraints.
[Link] Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect banking
system in any fashion.
2.2 THE OVERALL DESCRIPTION
2.2.1 Product perspective
[Link] Hardware interfaces
[Link].1 Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system (such
as any RDBMS) running on high rpm hard-disk permitting complete data
redundancy and backup systems to support the primary goal of reliability.
[Link].2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
[Link] Software interfaces

<24CS5504/SD lab> Lab Manual/CSE

16
 [Link].1 Back End: Oracle
[Link].2 Front End: Microsoft Visual Basic 6.0
[Link] Operations
[Link].1 The user can create a new account.
[Link].2 The existing user can access his account and view his balance by entering
his details.
[Link].2 The user can deposit and withdraw money from his account.
2.2.2 Product Functions
[Link] Creating a New Account
The user should provide his personal details to facilitate the bank clerk to create a new
account. The user should provide:
[Link].1 Customer Name.
[Link].2 Customer address.
[Link].3 Required account type.
[Link].4 Pin Number.
[Link].5 Initial deposit.
[Link] Operating with created account
The user should be able to operate with his new account after:
[Link].1 Entering card number.
[Link].2 Entering pin number.
[Link].3 Entering the account type, transaction type and amount involved in the
transaction.
2.2.3 User characteristics
[Link] The intended users of this software need not have specific knowledge as to what is
the internal operation of the system. Thus the end user is at a high level of
abstraction that allows easier, faster operation and reduces the knowledge
requirement of end user
[Link] The Product is absolutely user friendly, so the intended users can be the naïve
users.

<24CS5504/SD lab> Lab Manual/CSE

17
 [Link] The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use this
product.
2.2.4 Constraints:
[Link] At the time of creating the new account, each user gives a pin number and is
provided with a unique card number that must be used for further transactions.
Hence the user is required to remember or store these numbers carefully.
[Link] At the time of creating the new account, the initial deposit should not be less than
the specified amount.
2.3 SPECIFIC REQIREMENTS
2.3.1 Logical Database Requirements
[Link] The system should contain databases that include all the necessary information for the
product to function according to the requirements. These include relations such as
Customer Details and Account Details.
[Link] Customer details refer to the customer’s name and address. Account details of the
customer include the card number, account type, transaction type and the pin number
given by the user to be used at the time of the transaction at the bank.
2.4 FRONT – END DESCRIPTION
The front end for the Automated Banking System (ABS) is designed using Microsoft Visual
Basic 6.0. The front end contains a user-friendly interface. The first form contains a welcome screen
that provides an option for the user to either crate a new account or to operate through an existing
account. The “create account” module contains a provision to crate a new account after collecting the
customer name, address and other details. The card number and pin number of the user is obtained
every time there is a transaction. The user is requested to select the required type of transaction and
the amount involved in the transaction.
2.5 BACK – END DESCRIPTION
The Automated Banking System (ABS) database contains only one table. It correlates a
unique card number, customer name, account type, pin number and the balance.

<24CS5504/SD lab> Lab Manual/CSE

18
2.6 DATA FLOW DIAGRAM:

Administrator

Display
summar
y report
User Queries
for

Commits
transactio
Enters a/c
number + Databas
pin number e Updat
e

Checks
for Generate
availabilit s error
Displays y
report on
Enters
details

<24CS5504/SD lab> Lab Manual/CSE

19
3.0 TESTING
FORM NAME INPUT EXPECTED ACTUAL STATUS
OUTPUT OUTPUT
MAIN FORM Existing user Menu form Menu form was Pass
must be displayed
displayed
MENU FORM Card and pin Validate card Card and pin Pass
numbers and pin number number were
validated
CUSTOMER User details are Create a new New account Pass
DETAILS entered account was created
DEPOSIT Amount to be Deposit amount Amount was Pass
FORM deposited is deposited
entered
WITH DRAW Amount to be Withdraw Amount was Pass
FORM withdrawn is amount withdrawn
entered

<24CS5504/SD lab> Lab Manual/CSE

20
4.0 SAMPLE FORM

NEWACCOUNTFORM

<24CS5504/SD lab> Lab Manual/CSE

21
CUSTOMER INFORMATION FORM

TRANSACTION FORM (WITHDRAW)

<24CS5504/SD lab> Lab Manual/CSE

22
TRANSACTION FORM (DEPOSIT)

<24CS5504/SD lab> Lab Manual/CSE

23
5.0 RESULT
Thus the requirements involved in developing an Automated Banking System was completed
successfully

<24CS5504/SD lab> Lab Manual/CSE

24
EX NO :4
Date :
LIBRARY MANAGEMENT SYSTEM

1.0 PROBLEM DEFENITION

The library management system is software, which automates the job of a librarian.
1.1 The user can inquire about the availability of a book in which he can search by entering
the author’s name or by entering the title of the book.
1.2 The user can borrow a book. He must provide the username and the card number, which is
unique and confidential to each user. By confirming the authenticity of a user, the library
management system provides information about the number of books already borrowed by
the user and by referring to the database whether the user can borrow books or not. The
library management system allows the user to enter the title and the author of the book
and hence issues the book if it is available.
1.3 By entering the user details and the book details the user can return the borrowed book.

2.0 SYSTEM REQUIREMENT SPECIFICATION

2.1 INTRODUCTION
2.1.1 Purpose
[Link] The purpose of this SRS is to describe the requirements involved in
developing a Library management system.
[Link] The intended audience is any person, who wants to inquire, borrow and
return the books.
2.1.2 Scope
[Link] The product is titled Library Management System.
[Link] The product will perform the following tasks
[Link].1 Enquire about the availability of books.
[Link].2 Borrow books if available.
[Link].3 Return the borrowed books.
2.1.3 Definitions, Acronyms and Abbreviations

<24CS5504/SD lab> Lab Manual/CSE

25
 [Link] DDBMS – Database Management System.
2.1.4 References
[Link] IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
[Link] The SRS contains an analysis of the requirements necessary to help easy design.
[Link] The overall description provides interface requirements for the Library
Management System, product perspective, hardware interfaces, software
interfaces, communication interface, memory constraints, product functions, user
characteristics and other constraints.
[Link] Succeeding pages illustrate the characteristics of typical naïve users accessing
the system along with legal and functional constraints enforced that affect
Library Management System in any fashion.
2.2 THE OVERALL DESCRIPTION
2.2.1 Product perspective
[Link] Hardware interfaces
[Link].1 Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system
running on high rpm hard disk permitting complete data redundancy and
back-up systems to support the primary goal of reliability.
[Link].2 The system must interface with the standard output devise, keyboard and
mouse to interact with this software.
[Link] Software interfaces
[Link].1 Back End: MS-Access
[Link].2 Front End: Microsoft Visual Basic 6.0
[Link] Memory Constraints
[Link].1 No specific constraints on memory.
[Link] Operations
[Link].1 The software allows three modes of operations
[Link].1.1 Enquire about the availability and status of
books.

<24CS5504/SD lab> Lab Manual/CSE

26
 [Link].1.1 By extracting the username and password the software allows the
user to borrow a maximum of three books.
[Link].1.2 By extracting the username and password the software allows the
user to return the borrowed books.
2.2.2 Product Functions
[Link].1 Enquire about the availability and status of books.
[Link].2 Search the availability of book by entering the title of the book.
[Link].3 Search the availability of book by entering the author of the book.
[Link].4 The software validates the authentic user by extracting their user name
and password.
[Link].5 After the validation of the user software allows the user to borrow a maximum of
three books based on the number of books which where already borrowed.
[Link].6 After the validation of the user software allows the user to return the books,
which where borrowed.
2.2.3 User characteristics
[Link] The intended users of this software need not have specific knowledge as to what is
the internal operation of the system. Thus the end user is at a high level of
abstraction that allows easier, faster operation and reduces the knowledge
requirement of end user
[Link] The Product is absolutely user friendly, so the intended users can be the naïve
users.
[Link] The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use this
product.
2.2.4 Constraints
[Link] The user has a unique username and password, there are no options to retrieve a
password or username incase it is forgotten or lost hence the user is requited to
remember or store the username and password.
2.3 SPECIFIC REQIREMENTS
2.3.1 Logical Database Requirements

<24CS5504/SD lab> Lab Manual/CSE

27
 [Link] The system should contain databases that include all necessary information for the product
to function according to the requirements. These include relations such as user details and
book details.
[Link] The user details refer to the information such as name, card number, no. of books
borrowed, the title and the name of the author of the books that were borrowed.
[Link] The book details refer to the information such as the title of the book, author availability
status and the number of copies that is available.

2.4 FRONT – END DESCRIPTION

The library management system is automated library system where the user can search for the
book by either entering the details of the book or the author’s name. By entering the username and
the password the software, by checking the number of books that are already borrowed enables us to
borrow a maximum of three books. And by entering the username and password (card number),
which is unique, the user can return the books.

2.5 BACK – END DESCRIPTION

The library management system consists of two tables. One contains the student details such
as the name, card number that is the password, title and the author of the three books, which could be
borrowed. The book details consist of the title of the book, number of copies, author and the
availability status.

<24CS5504/SD lab> Lab Manual/CSE

28
2.6 DATA FLOW DIAGRAM

Display
s
Compute
s fine

Databas
e about

Update
s

Enters
For For
Use registrati For ISSUE
r RENEWAL RETURN
on

Queries Update
for Enters s
details of
Issues required Update
the s

Master
Administrator
database
Add /
Modify /
Delete Update
s

Enters
Confirmatio
related n

3.0 TESTING:

<24CS5504/SD lab> Lab Manual/CSE

29
 FORM NAME INPUT EXPECTED ACTUAL STATUS
OUTPUT OUTPUT
MAIN FORM Enquiry Enquiry Enquiry Form Pass
was displayed
ENQUIRY Book name is Display the Entered Book Pass
FORM entered books was displayed
BORROW Title of the book, If the book is Book issued Pass
FORM authors name available, Issue
and the the book
borrower name
are entered
RETURN Title of the book, Book Returned Book returned Pass
FORM authors name
and the
borrower name
are entered

<24CS5504/SD lab> Lab Manual/CSE

30
4.0 SAMPLE FORMS

MAIN FORM

<24CS5504/SD lab> Lab Manual/CSE

31
ENQUIRY FORM

<24CS5504/SD lab> Lab Manual/CSE

32
BORROW FORM

<24CS5504/SD lab> Lab Manual/CSE

33
BOOK MAINTENANCE FORM

<24CS5504/SD lab> Lab Manual/CSE

34
5.0 RESULT:
Thus the online Library System was implemented using the specified front end and back end
tools.

<24CS5504/SD lab> Lab Manual/CSE

35
EX NO :5
Date :
RAILWAY RESERVATION SYSTEM

1.0 PROBLEM DEFENITION

Ticket reservation system for railway department has to be developed.
The system developed should contain the following features
1. The system should contain the following features
2. Search for information about the train by means of train number and destination
3. While displaying information about the train it has to provide availability of seats in
different classes (first class , second class, a.c)
4. While reserving tickets the system obtain following information from the user
Passenger Name, Sex, Age, Address.
Credit Card Number, Bank Name.
Class through passenger is going to travel i.e first class/second class/A.C
Train number, Train name, Date of Journey and number of tickets to be booked.
5. Based on the availability of tickets, the ticket has to be issued. The ticket issued should
contain the following information –PNR number, train no, train name, date of journey,
class, number of passengers, sex, age and departure time.
6. Cancellation of booked tickets should be available.

2.0 SRS DOCUMENT FOR RAILWAY RESERVATION SYSTEM

2.1 INTRODUCTION
2.1.1 Purpose
[Link] The purpose of this SRS is to describe the requirements involved in
developing a Railway Reservation system (RRS).
[Link] The intended audience is any person who wants to reserve or cancel
tickets or to check the availability of Railway tickets
2.1.2 Scope
[Link] The product is titled Railway Reservation system (RRS).

<24CS5504/SD lab> Lab Manual/CSE

36
 [Link] The product will perform the following tasks
[Link].1 The software that is being developed can be used to check the availability of
the train tickets for the specified train, destination and date of journey
[Link].2 If the tickets are available to the users needs and specification, then the
software provide a facility to book the tickets.
[Link].3 If the passengers wants to cancel the tickets, he can use the cancellation
module of the Railway Reservation System.
2.1.3 Definitions, Acronyms and Abbreviations
[Link] RRS: Railway Reservation System.
2.1.4 References
[Link] IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
[Link] The SRS contains an analysis of the requirements necessary to help easy design.
[Link] The overall description provides interface requirements for the Railway
Reservation system, Reservation System, product perspective, hardware interfaces
software interfaces,, communication interface, memory constraints, product
functions, user characteristics and other constraints.
[Link] Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect Railway
Reservation system in any fashion.
2.2 THE OVERALL DESCRIPTION
2.2.1 Product perspective
[Link] Hardware interfaces
[Link].1 Hard disk: The database connectivity requires a hardware configuration
with a fast database system running on high rpm hard-disk permitting
complete data redundancy and back-up systems to support the primary goal
of reliability.
[Link].2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
[Link] Software interfaces

<24CS5504/SD lab> Lab Manual/CSE

37
 [Link].1 Back End: Oracle
[Link].2 Front End: Microsoft Visual Basic 6.0
[Link] Operations
[Link].1 The user mode enables the end-users to do the end user operations like
checking the availability, reserving and canceling of train tickets.
2.2.2 Product Functions
[Link] Viewing Train Details
The user must have the access up-to-date information about the trains including [Link].1Train
number
[Link].2 Train Name
[Link].3 Train route(Start and Destination stations)
[Link].4 Train timings
[Link].5 Seat availability in each class.
[Link] Reserving Tickets
The user must be able to reserve tickets after selecting [Link].1Train
number
[Link].2 Train Name
[Link] Canceling Tickets
The user must be able to cancel tickets that he has earlier reserved by quoting the PNR
number, credit card number and bank name.
2.2.3 User characteristics
[Link] The intended users of this software need not have specific knowledge as to what is
the internal operation of the system. Thus the end user is at a high level of
abstraction that allows easier, faster operation and reduces the knowledge
requirement of end user
[Link] The Product is absolutely user friendly, so the intended users can be the naïve
users.
[Link] The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use this
product.
2.2.4 Constraints

<24CS5504/SD lab> Lab Manual/CSE

38
 [Link] At the time of reservation, each user is provided a unique PNR number that must
be used for further operation like cancellation. Hence the user is required to
remember or store this number carefully.

2.3 SPECIFIC REQIREMENTS

2.3.1 Logical Database Requirements
[Link] The system should contain databases that include all necessary information for the product
to function according to the requirements. These include relations such as train details,
reservation details, and cancellation details.
[Link] The user details refer to the information such as train number and name, start and
destination stations, seat availability.
[Link] Reservation details refer to personal information that is obtained from the user
[Link] At the time of reservation, the passenger is provided a unique PNR no that could be used
at the time of cancellation.
[Link] While displaying any information about the train it has to provide the following
information
Train no and name
Availability of seats for the particular train The train
timing
The passenger personal details should be obtained for reserving the tickets.

2.4 FRONT – END DESCRIPTION

The front-end for the Railway Reservation system (RRS) is designed using Microsoft Visual
Basic 6.0. The front-end contains a user- friendly interface. The first form contains a welcome screen
that provides an option for the user to select one of the following
Enquiry Reservation
Booking details
Cancellation
In the Enquiry form the user can get details of the train by means of either train name
destination or date 0of journey. In the reservation form, there can book details by entering the

<24CS5504/SD lab> Lab Manual/CSE

39
personal details. The ticket is displayed with details about the train name and number, number of
passengers, PNR number, class, sex and age. The cancellation form helps the user to cancel a ticket,
which he had booked earlier.

2.5 BACK – END DESCRIPTION

The Railway Reservation system consists of two tables. One contains the train details such as
the train name, train number, destination, date of journey and seats available in each class that is
referred to during enquiry. The other table has the passenger details such as name, age, sex, credit
card number, and bank name. This table is referred to at the time of reservation or cancellation.

2.6 DATA FLOW DIAGRAM

Passenger

Validate
Inputs train inputed
and
personal Generate
error

Check
for
Operator

Updat
e Issue
ticket
Databas
e

<24CS5504/SD lab> Lab Manual/CSE

40
3.0 TESTING:

FORM NAME INPUT EXPECTED ACTUAL STATUS

OUTPUT OUTPUT
Title Enquiry was Enquiry form Enquiry form Pass
clicked. must be was displayed.
displayed.
Enquiry Train name was Train details Train details Pass
clicked. must be were displayed.
displayed
Reservation Personal details Ticket must be Ticket was Pass
were entered. booked and booked and
database database was
updated. updated.
Booking Details PNR number Booking details Booking details Pass
was entered. must be were displayed.
displayed.
Cancellation PNR number Ticket must be Ticket was Pass
was entered cancelled and cancelled and
database must database was
be updated. updated.

<24CS5504/SD lab> Lab Manual/CSE

41
4.0 SAMPLE FORMS
TITLE FORM

RESERVATION FORM

<24CS5504/SD lab> Lab Manual/CSE

42
CANCELLATION FORM

<24CS5504/SD lab> Lab Manual/CSE

43
5.0 RESULT

Thus the online Railway Reservations System was implemented using the specified front end
and back end tools.

<24CS5504/SD lab> Lab Manual/CSE

44
EX NO :6
Date :
TRADING SYSTEM

1.0 PROBLEM DEFENITION

The requirement to be developed is an Trading system which is required to perform the following
functions.
1.1 It should allow user to view stock details of each part which must include part number,
part name, demand per day, setup cost, holding cost, lead time, cycle time, EOQ, order
amount and availability.
1.2 It should allow the user to take parts required for production.
1.3 It should allow the user to order required units of production.
1.3 It should allow the user to add a new part to the stock.

2.0 SRS DOCUMENT FOR INVENTORY SYSTEM

2.1 INTRODUCTION
2.1.1 Purpose
[Link] The purpose of this SRS is to describe the requirements involved in
developing an Inventory system.
[Link] The intended audience is any person who wants
[Link].1 To view stock details.
[Link].2 To take parts from stock production.
[Link].3 To order required parts of any unit.
2.1.2 Scope
[Link] The product is titled Inventory System.
[Link] The product will perform the following tasks
[Link].1 It should allow the user to view stock details of each part which must include
part number, part name, demand per day, set up cost, holding cost, lead time,
cycle time, order amount and availability.
[Link].2 Allow the user to take required parts from production.

<24CS5504/SD lab> Lab Manual/CSE

45
 [Link].3 Allow the user to order required parts of production.
[Link].4 Allow the user to add a new part to the stock.
2.1.3 References
[Link] IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.4 Overview
[Link] The SRS contains an analysis of the requirements necessary to help easy design.
[Link] The overall description provides interface requirements for the Payroll Inventory
System, product perspective, hardware interfaces, software interfaces,
communication interface, memory constraints, product functions, user
characteristics and other constraints.

[Link] Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect Inventory
System in any fashion.

2.2 THE OVERALL DESCRIPTION

2.2.1 Product perspective
[Link] Hardware interfaces
[Link].1 Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system (such
as any RDBMS) running on high rpm hard-disk permitting complete data
redundancy and backup systems to support the primary goal of reliability.
[Link].2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
[Link] Software interfaces
[Link].1 Back End: Oracle
[Link].2 Front End: Microsoft Visual Basic 6.0
[Link] Memory Constraints
[Link].1 No specific constraints on memory.
[Link] Operations

<24CS5504/SD lab> Lab Manual/CSE

46
 [Link].1 The software allows two modes of operations
[Link].1.1 The user mode allows users to view stock details take parts from
stock for production, order for required parts and add a new part.
2.2.2 Product Functions
[Link] Viewing the stock details
The user must have the access to Up-to-date information about the stocks.
[Link].1 Part number
[Link].2 Part Name
[Link].3 Set up cost
[Link].4 Demand
[Link].5 Holding cost
[Link].6 Lead time
[Link].7 Cycle time
[Link].8 Order
[Link].9 Availability.
[Link] Taking parts from stock
The user must be able to take parts from stocks by supplying the following information
about the stock.
[Link].1 Part number.
[Link].2 Required units.
[Link] Ordering parts
The user can add the required number of parts by giving the following information.
[Link].1 Part number.
[Link].2 Required units.
[Link] Adding a new part
The user must be able to add a new part by providing the following information
[Link].1 Part number
[Link].2 Set up cost
[Link].3 Demand
[Link].4 Lead time

<24CS5504/SD lab> Lab Manual/CSE

47
 [Link].5 Holding cost
[Link].6 Availability.
2.2.3 User characteristics
[Link] The intended users of this software need not have specific knowledge as to what is
the internal operation of the system. Thus the end user is at a high level of
abstraction that allows easier, faster operation and reduces the knowledge
requirement of end user
[Link] The Product is absolutely user friendly, so the intended users can be the naïve
users.
[Link] The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use this
product.

2.3 SPECIFIC REQIREMENTS

2.3.1 Logical Database Requirements
[Link] There are two databases, one which contains all the necessary information about the
customer which includes customer ID, customer name, address and phone number.
The other database contains information about the stock which includes part number,
part name and availability.

2.4 FRONT – END DESCRIPTION

The front end for the Inventory System is designed using Microsoft Visual Basic 6.0. The
front end contains a user friendly interface. The user can view the customer details and stock details,
user can order required units of any part or add part to the stock.

2.5 BACK – END DESCRIPTION

There are two tables. The customer table correlates a unique customer ID with his name,
address and telephone number. The stock table contains the part number, part name and availability
details.

<24CS5504/SD lab> Lab Manual/CSE

48
2.6 DATA FLOW DIAGRAM

Administrator

Input details Identify items

about the with
new items insufficient
Input
details
from the
Retrieve
and

Updat
e
Generat
Verify Databas
details e
e

<24CS5504/SD lab> Lab Manual/CSE

49
3.0 TESTING

FORM NAME INPUT EXPECTED ACTUAL STATUS

OUTPUT OUTPUT
Form 1 Stock details Stock details Stock details Pass
form must be form was
displayed. displayed.
Form 2 Customer ID Customer Customer Pass
details must be details were
displayed. displayed.
Form 3 Part number Stock details Stock details Pass
including part were displayed.
name and
availability must
be displayed.
Form 4 Part number and The no. of units The no. of units Pass
number of of the specified of the specified
required parts. part must be part was ordered
ordered or or added to the
added to the stock.
stock

<24CS5504/SD lab> Lab Manual/CSE

50
4.0 SAMPLE FORMS

<24CS5504/SD lab> Lab Manual/CSE

51
<24CS5504/SD lab> Lab Manual/CSE

52
5.0 RESULT

Thus the online Trading System was implemented using the specified front end and back end
tools.

<24CS5504/SD lab> Lab Manual/CSE

53
EX NO :7
Date :
CELLULAR PHONE SYSTEM

1.0 PROBLEM DEFENITION

The software for cellular phone system has been developed. The system development should contain
the following functions:
1.1 The cell numbers can be added with its information.
1.2 Messages can be sent from one number to the other number
1.3 Information about a cell number can be viewed.
1.4 The inbox and outbox automatically get updated when message is sent and received.

2.0 SRS DOCUMENT FOR CELLULAR PHONE SYSTEM

2.1 INTRODUCTION
2.1.1 Purpose
[Link] The purpose of this SRS is to describe the requirements involved in
developing a Cellular System.
[Link] The intended audience is any person who wants to send message to
another person will type the message and choose the destination number.
2.1.2 Scope
[Link] The product is titled Cellular.
[Link] The product will perform the following tasks
[Link].1 It enables to transfer messages from one number to the other number.
[Link].2 It displays information about the particular cell number.
2.1.3 References
[Link] IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.4 Overview
[Link] The SRS contains an analysis of the requirements necessary to help easy design.

<24CS5504/SD lab> Lab Manual/CSE

54
 [Link] The overall description provides interface requirements for the Cellular System,
product perspective, hardware interfaces, software interfaces, communication
interface, memory constraints, product functions, user characteristics and other
constraints.
[Link] Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect Cellular
System in any fashion.
2.2 THE OVERALL DESCRIPTION
2.2.1 Product perspective
[Link] Hardware interfaces
[Link].1 Hard disk: The database connectivity requires a hardware configuration
that is on-line. This makes it necessary to have a fast database system (such
as any RDBMS) running on high rpm hard-disk permitting complete data
redundancy and back-up systems to support the primary goal of reliability.
[Link].2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
[Link] Software interfaces
[Link].1 Back End: Oracle
[Link].2 Front End: Microsoft Visual Basic 6.0
[Link] Operations
[Link].1 The user mode enables the end users to do the end user operations
like to choose a cell number and do the necessary operations.
2.2.2 Product Functions
[Link] The software transfers the text messages from one cellular number to the other
chosen cellular number
[Link] The new cellular number can be added should not affect the other existing cellular
numbers.
2.2.3 User characteristics
[Link] The intended users of this software need not have specific knowledge as to what is
the internal operation of the system. Thus the end user is at a high level of

<24CS5504/SD lab> Lab Manual/CSE

55
 abstraction that allows easier, faster operation and reduces the knowledge requirement of
end user
[Link] The Product is absolutely user friendly, so the intended users can be the naïve
users.
[Link] The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use this
product.
2.2.4 Constraints
[Link] Once the cellular number has been chosen it must ask for the operations to be
done.
[Link] When an operation is chosen the user has to follow the steps displayed by the
system to complete it.
2.3 SPECIFIC REQIREMENTS
2.3.1 Logical Database Requirements
[Link] The system should contain databases that include all necessary information for the product
to function according to the requirements. These include relation such as cellular number,
owner’s name, date of birth and address.
[Link] Cellular details refers to the information such as cellular number, owner’s name and the
usage.

2.4 FRONT – END DESCRIPTION

The front end for the Cellular System is designed using Microsoft Visual Basic 6.0. The front
– end contains a user – friendly interface. The form contains a welcome screen that provides an
option for the user to select any one of the following:
I) Enquiry
II) Message
III) Add new entry

In the enquiry form the user can get the cellular number. In the message form the user can
choose a number, type the message and send it to the required number.

<24CS5504/SD lab> Lab Manual/CSE

56
2.5 BACK – END DESCRIPTION
There are two oracle tables created. One of them consists of cellular number details such as
name, number, and address. The other table has the message details such as name, number, inbox and
outboxes. This table is referred to at the time of transfer messages.

2.6 DATA FLOW DIAGRAM

USER

CREATE
NEW
ACCOUNT

DATABASE

EDIT

TARIFF
PLAN

<24CS5504/SD lab> Lab Manual/CSE

57
3.0 TESTING:

FORM NAME INPUT EXPECTED ACTUAL STATUS

OUTPUT OUTPUT
CELLULAR The user enters Check whether If the number is Pass
FORM a cellular the number is in in the database
number database accept else error
message is
displayed
MESSAGE The message is The inbox must The inbox was Pass
FORM entered be updated updated

4.0 SAMPLE FORMS

TYPE OF SERVICE

<24CS5504/SD lab> Lab Manual/CSE

58
NEW CONNECTION

PLAN TARIFF

<24CS5504/SD lab> Lab Manual/CSE

59
EDIT RECORD

<24CS5504/SD lab> Lab Manual/CSE

60
5.0 RESULT
Thus the cellular System was implemented using the specified front end and back end tools.

<24CS5504/SD lab> Lab Manual/CSE

61