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
2.2.1.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.
2.2.1.2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
2.2.2 Software interfaces
2.2.2.1.1 Back End: MS-Access
2.2.2.1.2 Front End: Microsoft Visual Basic 6.0
2.2.3 Memory Constraints
 2.2.1.3.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 Course

Fees

Balance DO Pay

Fees Pay Enquiries

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

5.0 RESULT:
Thus the online student course registration System was implemented using the specified front end
and back end tools.
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
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing a Payroll Processing System. (PPA).
2.1.1.2 The intended audience is any person who wants
2.1.1.2.1 To check employee details (both employee and administrator
mode).
2.1.1.2.2 To add new employee, modify any employee’s details or generate
payroll for the employee (only administer mode).
2.1.2 Scope
2.1.2.1 The product is titled Payroll Processing Application.
2.1.2.2 The product will perform the following tasks
2.1.2.2.1 Allow either an employee or an administrator to view employee details.
2.1.2.2.2 Allow the administrator to add a new employee with corresponding details.
2.1.2.2.3 Allow the administrator to modify the detail of an employee.
2.1.2.2.4 Allow the administrator to generate the payroll for the employee.
2.1.3 Definitions, Acronyms and Abbreviations
2.1.3.1 PPA: Payroll Processing System.
2.1.4 References
2.1.4.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
2.1.5.1 The SRS contains an analysis of the requirements necessary to help easy design.
2.1.5.2 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.
2.1.5.3 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
2.2.1.1 Hardware interfaces
2.2.1.1.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.
2.2.1.1.2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
2.2.1.2 Software interfaces
2.2.1.2.1 Back End: Oracle
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Memory Constraints
2.2.1.3.1 No specific constraints on memory.
2.2.1.4 Operations
2.2.1.4.1 The software allows two modes of operations
 2.2.1.4.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
2.2.2.1 Viewing the employee details
The user (both administrator and employee) must have the access to Up-to-date
information about the employee including
2.2.2.1.1 Employee Id
2.2.2.1.2 Employee Name
2.2.2.1.3 Employee Department
2.2.2.1.4 Date of Joining
2.2.2.1.5 Salary
2.2.2.2 Adding a new employee
The user (only in administrator mode) must be able to add a new employee by
supplying the following employee details.
2.2.2.2.1 Employee Name
2.2.2.2.2 Employee Department
2.2.2.2.3 Date of Joining
2.2.2.2.4 Salary
2.2.2.3 Modifying the details of an employee
The user (only in administrator mode) must be able to modify the following details
of an existing employee.
2.2.2.3.1 Employee Name
2.2.2.3.2 Employee Department
2.2.2.3.3 Date of Joining
2.2.2.3.4 Salary
2.2.3 User characteristics
2.2.3.1 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
 2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
2.2.3.3 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
2.2.4.1 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
2.3.1.1 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.
2.6 A FLOW DIAGRAM
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

5.0 RESULT
Thus the Payroll System was implemented using the specified front end and back end tools.
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
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing an Automated Banding System (ABS).
2.1.1.2 The intended audience is any person who wants
2.1.1.2.1 To create account.
2.1.1.2.2 To withdraw or deposit either in fixed deposit or credit account.
2.1.2 Scope
2.1.2.1 The product is titled Automated Banking System (ABS).
2.1.2.2 The product will perform the following tasks
2.1.2.2.1 Allow a new user to create an account, either fixed or credit account by
entering the details and by depositing an initial amount.
2.1.2.2.2 Allow the existing user to enter his account details like card number, pin
number and account type to view his balance.
2.1.2.2.3 Allow the existing user to deposit an amount by entering the amount to be
deposited after the balance had been viewed.
 2.1.2.2.4 Allow the existing user to withdraw an amount by entering the amount to be
withdrawn after the balance had been viewed.
2.1.2.2.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
2.1.3.1 ABS: Automated Banking System.
2.1.4 References
2.1.4.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.4.2 IEEE Software Requirements Specifications Template
http://www.cas.master.ca/~carette/SE3M04/2003/files/
srs_template.doc
2.1.5 Overview
2.1.54.1 The SRS contains an analysis of the requirements necessary to help easy design.
2.1.5.2 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.
2.1.5.3 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
2.2.1.1 Hardware interfaces
2.2.1.1.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.
2.2.1.1.2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
2.2.1.2 Software interfaces
 2.2.1.2.1 Back End: Oracle
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Operations
2.2.1.3.1 The user can create a new account.
2.2.1.3.2 The existing user can access his account and view his balance by entering
his details.
2.2.1.3.2 The user can deposit and withdraw money from his account.
2.2.2 Product Functions
2.2.2.1 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:
2.2.2.1.1 Customer Name.
2.2.2.1.2 Customer address.
2.2.2.1.3 Required account type.
2.2.2.1.4 Pin Number.
2.2.2.1.5 Initial deposit.
2.2.2.2 Operating with created account
The user should be able to operate with his new account after:
2.2.2.2.1 Entering card number.
2.2.2.2.2 Entering pin number.
2.2.2.2.3 Entering the account type, transaction type and amount involved in the
transaction.
2.2.3 User characteristics
2.2.3.1 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
2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
 2.2.3.3 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:
2.2.4.1 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.
2.2.4.2 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
2.3.1.1 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.
2.3.1.2 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.
2.6 DATA FLOW DIAGRAM:

Administrator

Display
summary
report
User Queries for
details

Commits
transaction
Enters a/c
number + pin Database
number Update

Checks for
availability Generates
Enters details error report
Displays report
about new
on a/c details
transaction
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
4.0 SAMPLE FORM

NEWACCOUNTFORM
CUSTOMER INFORMATION FORM

TRANSACTION FORM (WITHDRAW)

TRANSACTION FORM (DEPOSIT)
5.0 RESULT
Thus the requirements involved in developing an Automated Banking System was completed
successfully
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
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing a Library management system.
2.1.1.2 The intended audience is any person, who wants to inquire, borrow and
return the books.
2.1.2 Scope
2.1.2.1 The product is titled Library Management System.
2.1.2.2 The product will perform the following tasks
2.1.2.2.1 Enquire about the availability of books.
2.1.2.2.2 Borrow books if available.
2.1.2.2.3 Return the borrowed books.
2.1.3 Definitions, Acronyms and Abbreviations
 2.1.3.1 DDBMS – Database Management System.
2.1.4 References
2.1.4.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
2.1.5.1 The SRS contains an analysis of the requirements necessary to help easy design.
2.1.5.2 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.
2.1.5.3 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
2.2.1.1 Hardware interfaces
2.2.1.1.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.
2.2.1.1.2 The system must interface with the standard output devise, keyboard and
mouse to interact with this software.
2.2.1.2 Software interfaces
2.2.1.2.1 Back End: MS-Access
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Memory Constraints
2.2.1.3.1 No specific constraints on memory.
2.2.1.4 Operations
2.2.1.4.1 The software allows three modes of operations
2.2.1.4.1.1 Enquire about the availability and status of books.
 2.6.1.1.1.1 By extracting the username and password the software allows the
user to borrow a maximum of three books.
2.6.1.1.1.2 By extracting the username and password the software allows the
user to return the borrowed books.
2.2.2 Product Functions
2.2.2.1.1 Enquire about the availability and status of books.
2.2.2.1.2 Search the availability of book by entering the title of the book.
2.2.2.1.3 Search the availability of book by entering the author of the book.
2.2.2.1.4 The software validates the authentic user by extracting their user name and
password.
2.2.2.1.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.
2.2.2.1.6 After the validation of the user software allows the user to return the books,
which where borrowed.
2.2.3 User characteristics
2.2.3.1 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
2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
2.2.3.3 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
2.2.4.1 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
 2.3.1.1 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.
2.3.1.2 The user details refer to the information such as name, card number, no. of booksborrowed,
the title and the name of the author of the books that were borrowed.
2.3.1.3 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.
2.6 DATA FLOW DIAGRAM

report

Enters
For For
number

details

item
item

Administrator
about items

Delete
Records

details

3.0 TESTING:
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 If the book is Book issued Pass
FORM book, authors available, Issue
name and the the book
borrower name
are entered
RETURN Title of the Book Returned Book returned Pass
FORM book, authors
name and the
borrower name
are entered
4.0 SAMPLE FORMS

MAIN FORM
ENQUIRY FORM
BORROW FORM
BOOK MAINTENANCE FORM
5.0 RESULT:
Thus the online Library System was implemented using the specified front end and back end
tools.
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
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing a Railway Reservation system (RRS).
2.1.1.2 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
2.1.2.1 The product is titled Railway Reservation system (RRS).
 2.1.2.2 The product will perform the following tasks
2.1.2.2.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
2.1.2.2.2 If the tickets are available to the users needs and specification, then the
software provide a facility to book the tickets.
2.1.2.2.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
2.1.3.1 RRS: Railway Reservation System.
2.1.4 References
2.1.4.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.5 Overview
2.1.5.1 The SRS contains an analysis of the requirements necessary to help easy design.
2.1.5.2 The overall description provides interface requirements for the Railway Reservation
system, Reservation System, product perspective, hardware interfaces software
interfaces,, communication interface, memory constraints, productfunctions, user
characteristics and other constraints.
2.1.5.3 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
2.2.1.1 Hardware interfaces
2.2.1.1.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.
2.2.1.1.2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
2.2.1.2 Software interfaces
 2.2.1.2.1 Back End: Oracle
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Operations
2.2.1.3.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
2.2.2.1 Viewing Train Details
The user must have the access up-to-date information about the trains including
2.2.2.1.1Train number
2.2.2.1.2 Train Name
2.2.2.1.3 Train route(Start and Destination stations)
2.2.2.1.4 Train timings
2.2.2.1.5 Seat availability in each class.
2.2.2.2 Reserving Tickets
The user must be able to reserve tickets after selecting
2.2.2.2.1Train number
2.2.2.2.2 Train Name
2.2.2.3 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
2.2.3.1 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
2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
2.2.3.3 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
 2.2.4.1 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
2.3.1.1 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.
2.3.1.2 The user details refer to the information such as train number and name, start and
destination stations, seat availability.
2.3.1.3 Reservation details refer to personal information that is obtained from the user
2.3.1.4 At the time of reservation, the passenger is provided a unique PNR no that could be used
at the time of cancellation.
2.3.1.5 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
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 details
and personal
details Generate error
report

Check for

Operator

Update
Issue ticket

Database
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.
4.0 SAMPLE FORMS
TITLE FORM

RESERVATION FORM
CANCELLATION FORM
5.0 RESULT

Thus the online Railway Reservations System was implemented using the specified front end
and back end tools.
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
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing an Inventory system.
2.1.1.2 The intended audience is any person who wants
2.1.1.2.1 To view stock details.
2.1.1.2.2 To take parts from stock production.
2.1.1.2.3 To order required parts of any unit.
2.1.2 Scope
2.1.2.1 The product is titled Inventory System.
2.1.2.2 The product will perform the following tasks
2.1.2.2.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.
2.1.2.2.2 Allow the user to take required parts from production.
 2.1.2.2.3 Allow the user to order required parts of production.
2.1.2.2.4 Allow the user to add a new part to the stock.
2.1.3 References
2.1.3.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.4 Overview
2.1.4.1 The SRS contains an analysis of the requirements necessary to help easy design.
2.1.4.2 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.

2.1.4.3 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
2.2.1.1 Hardware interfaces
2.2.1.1.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.
2.2.1.1.2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
2.2.1.2 Software interfaces
2.2.1.2.1 Back End: Oracle
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Memory Constraints
2.2.1.3.1 No specific constraints on memory.
2.2.1.4 Operations
 2.2.1.4.1 The software allows two modes of operations
2.2.1.4.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
2.2.2.1 Viewing the stock details
The user must have the access to Up-to-date information about the stocks.
2.2.2.1.1 Part number
2.2.2.1.2 Part Name
2.2.2.1.3 Set up cost
2.2.2.1.4 Demand
2.2.2.1.5 Holding cost
2.2.2.1.6 Lead time
2.2.2.1.7 Cycle time
2.2.2.1.8 Order
2.2.2.1.9 Availability.
2.2.2.2 Taking parts from stock
The user must be able to take parts from stocks by supplying the following
information about the stock.
2.2.2.2.1 Part number.
2.2.2.2.2 Required units.
2.2.2.3 Ordering parts
The user can add the required number of parts by giving the following
information.
2.2.2.3.1 Part number.
2.2.2.3.2 Required units.
2.2.2.4 Adding a new part
The user must be able to add a new part by providing the following information
2.2.2.4.1 Part number
2.2.2.4.2 Set up cost
2.2.2.4.3 Demand
2.2.2.4.4 Lead time
 2.2.2.4.5 Holding cost
2.2.2.4.6 Availability.
2.2.3 User characteristics
2.2.3.1 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
2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
2.2.3.3 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
2.3.1.1 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.
2.6 DATA FLOW DIAGRAM

Administrator

Input details Identify items

about the new with insufficient
items stocks
Input details
from the
customer

Retrieve and
verify

Update

Generate
Verify details Database
report
3.0TESTING

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
4.0SAMPLE FORMS
5.0RESULT

Thus the online Trading System was implemented using the specified front end and back end
tools.
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
2.1.1.1 The purpose of this SRS is to describe the requirements involved in
developing a Cellular System.
2.1.1.2 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
2.1.2.1 The product is titled Cellular.
2.1.2.2 The product will perform the following tasks
2.1.2.2.1 It enables to transfer messages from one number to the other number.
2.1.2.2.2 It displays information about the particular cell number.
2.1.3 References
2.1.3.1 IEEE standard 830-1998 recommended practice for Software Requirements
Specifications-Description.
2.1.4 Overview
2.1.4.1 The SRS contains an analysis of the requirements necessary to help easy design.
 2.1.4.2 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.
2.1.4.3 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
2.2.1.1 Hardware interfaces
2.2.1.1.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.
2.2.1.1.2 The system must interface with the standard output device, keyboard and
mouse to interact with this software.
2.2.1.2 Software interfaces
2.2.1.2.1 Back End: Oracle
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.1.3 Operations
2.2.1.3.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
2.2.2.1 The software transfers the text messages from one cellular number to the other
chosen cellular number
2.2.2.2 The new cellular number can be added should not affect the other existing cellular
numbers.
2.2.3 User characteristics
2.2.3.1 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
2.2.3.2 The Product is absolutely user friendly, so the intended users can be the naïve users.
2.2.3.3 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
2.2.4.1 Once the cellular number has been chosen it must ask for the operations to be done.
2.2.4.2 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
2.3.1.1 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.
2.3.1.2 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.
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
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
NEW CONNECTION

PLAN TARIFF
EDIT RECORD
5.0 RESULT
Thus the cellular System was implemented using the specified front end and back end tools.