for more details please send mail to email : rakshainfotech@gmail.

com Address: Raksha Infotech No 826, 9th Main, RPC Layout, Vijayanagar II Stage Bangalore - 560040. website : www.rakshainfotech.com

If you want to buy any of these projects then contact us or Send you postal address we will send the CD postal VPP, paid to the postman and collect CD.

SYNOPSIS PRODUCT STOCK MANAGEMENT

INTRODUCTION: The project entitled PRODUCT STOCK MANAGEMENT is to maintain the stock in the warehouse. PROJECT: PRODUCT STOCK MANAGEMENT is a software application maintaing the records related to goods in, goods out and stock. OBJECTIVE: The main objective of the application is to automate the existing system of manually maintaing the records of the goods in, goods out and stock. SCOPE: This application can be used by any warehouse to maintain the stock record.

PROBLEM DEFINITION: The transactions related to Goods In, Good Out and returns are maintained manually at present along with maintaining the accounts of the customers and the suppliers. All these are to be automated and an application is required to relate all of them relatively and logically so that the current system can be replaced and accepted without major changes and problems.

The application should provide quick access to the records maintained and must reveal the important reviews about the business so that the growth can be easily compared and should provide with the various reports showing the related details so that the important decisions could be taken easily.

SOFTWARE REQUIREMENT SPECIFICATION:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS document itself states in precise and explicit language those functions and capabilities a software system must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

SRS are typically developed during the first stages of "Requirements Development," which is the initial product development phase in which

information is gathered about what requirements are needed--and not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed. The National Bureau of Standards, IEEE (Standard No: 830-1984), and the U.S Department of Defense have all proposed candidate formats for software requirements specifications. The general structure is implemented with the related software application

INTRODUCTION: The project entitled PRODUCT STOCK MANAGEMENT is developed as part of the VI Semester RDBMS package project for the partial fulfillment of the BCA degree. It is a software application maintaing the records related to all the transactions occurring at the counter of a shop. OBJECTIVE: The main objective is to maintain the inventory records of a generic shop which deals in musical tapes. To keep accounts of Goods in, Goods Out To know the current position of the Stock Transaction report Stock maintenance

SCOPE: As this is generic software it can be used by a wide variety of outlets (Retailers and Wholesalers) to automate the process of manually maintaining the records related to the subject of maintaining the stock and material flows. GOAL: The main goal of the application is to maintain the records of stock, billing, details of In, Out of the product and their current stock positions with the company.

PACKAGE FOR FLOWER DISTRIBUTOR

INTRODUCTION: The project entitled PACKAGE FOR FLOWER DISTRIBUTOR is developed to manage the day to day transaction of the flower distributor. It is a software application maintain the records related to all the transactions occurring at the Flower Distributor of a shop. PROJECT: PACKAGE FOR FLOWER DISTRIBUTOR is a software application maintaning the records related to purchase, sales, returns, stock updating, cash and bank flows and the reorder level of music store. OBJECTIVE: The main objective of the application is to automate the existing system of manually maintaing the records of the counter sales, purchases, reorder levels, Supplier and Customer monetary positions and other related transactions made at the counter. The main objective is to maintain the inventory records of a generic shop which deals in musical tapes. To keep accounts of purchase and sales To know the current position of the debtors and creditors Bill generation Stock maintenance

SCOPE: This application can be used by any music store to automate the process of manually maintaining the records related to the subject of maintaining the stock and liquid flows.

PROBLEM DEFINITION: The transactions related to purchase, sale and returns are maintained manually at present along with maintaining the accounts of the customers and the suppliers. All these are to be automated and an application is required to relate all of them relatively and logically so that the current system can be replaced and accepted without major changes and problems. The application should provide quick access to the records maintained and must reveal the important reviews about the business so that the growth can be easily compared and should provide with the various reports showing the related details so that the important decisions could be taken easily. GOAL: The main goal of the application is to maintain the records of stock, billing, details of purchasers and sellers and their current financial positions with the company.

INFORMATION DESCRIPTION:

DETAIL DESCRIPTION OF THE PROBLEM: In the present situation the records of the counter transactions are maintained manually (i.e. the record of the sale, purchase, sales return, purchase return, cash, customer account, supplier account, etc), therefore the tasks like reviewing previous records or editing them are very difficult and time consuming and even the chances of making mistakes are higher.

INFORMATION CONTENT The complete details about each of the module described above are stored and related logically together to provide related and organized information.

INFORMATION FLOW The flow of the information can be better examined through the Flow diagram model described below with the following entities: Suppliers Purchases Purchase Returns Customers Sales Sale Returns Reorder Levels Cash Transactions Bank Transactions Stock Status Debtor status Creditor Status

HARDWARE REQUIREMENT

Pentium IV 2GHz or above 512MB RAM or higher 80GB HARD DISK Color Monitor, Keyboard, Mouse

SOFTWARE REQUIREMENT Operating System : Microsoft Windows XP or Vista Front End : Microsoft Visual Basic 2005 Back End : MS Access 2000 or Higher

HUMAN INTERFACE Input/Output forms Data Reports Options for adding, editing and removing the information from the database

SYNOPSIS:

INSURANCE MANAGEMENT
INTRODUCTION: The project entitled INSURANCE MANAGEMENT is a pilot project for small insurance company to manage their administration . PROJECT: INSURANCE MANAGEMENT is a software application maintaing the records related to Insurance Products. OBJECTIVE: The main objective of the application is to automate the existing system of manually maintaing the records agents, policies, premium, maturity, etc., SCOPE: This application can be used by any Insurance company to maintain the Insurance management, daily transactions, policy registration etc.,.

PROBLEM DEFINITION: The transactions related to Insurance policies, premiums, policy maturity, agents management, agent commission calculation etc.,. All these are to be automated and an application is required to relate all of them relatively and logically so that the current system can be replaced and accepted without major changes and problems. The application should provide quick access to the records maintained and must reveal the important reviews about the business so that the growth can be easily compared and should provide with the various reports showing the related details so that the important decisions could be taken easily.

SOFTWARE REQUIREMENT SPECIFICATION:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS document itself states in precise and explicit language those functions and capabilities a software system must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

SRS are typically developed during the first stages of "Requirements Development," which is the initial product development phase in which

information is gathered about what requirements are needed--and not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed. The National Bureau of Standards, IEEE (Standard No: 830-1984), and the U.S Department of Defense have all proposed candidate formats for software requirements specifications. The general structure is implemented with the related software application

INTRODUCTION: The project entitled INSURANCE MANAGEMENT is developed as pilot project to manage Insurance Company transactions. It is a software application marinating the records related to all the transactions occurring at the company. OBJECTIVE: The main objective is to maintain the inventory records of a generic shop which deals in musical tapes. To keep accounts Agents, Policies, Premiums To generate the monthly, Quarterly, Half Yearly and Yearly premiums Agents Commission Management Branch transaction details

SCOPE: As this is generic software it can be used insurance company basically it is a pilot project to manage insurance company transaction. On approval it can build as full fledged software, later it can be customizable to any other insurance companies. GOAL: The main goal of the application is to maintain the records of policies, policy holders, premiums, premium calculations, agents, agents commission management. Brach details management etc.,

Flight ticket Booking System

Document

Description 1. 2. 3. 4. 5. 6. Requirement Specification Functional Specification Design specification Database Design Test phase and text cases User Documentation

Page No 3 - 5 6 - 9 10-13 14-15 16-23 24-48

Software Requirements Specification (SRS)

Abstract
This document fully and formally describes the requirements of the proposed said project system. It sets out the functional and non-functional requirements and includes a description of the user interface and documentation and training requirements.

Introduction
Flight Ticket Booking system is to provide an option to customers to book the tickets online and to check the confirmation online. This system will help the this company to sell the flight tickets online. Unless like in the previous stage people as to walk into travel agency or this company ticket counter to buy the tickets. And also to check the flight timings. This problem is over come introducing this system.

Existing System
This is a small aviation company. They have one booking office at the central location. All customer as to come here to book the flight. Presently they maintain all bookings manually.

Proposed System
The proposed system is maintain the flight bookings in in-house environment. This project helpful for small aviation companies who booking their tickets at their premises.

Hardware Requirements

Pentium III 400MHz and Above 128MB RAM 15 Color Monitor Keyboard Mouse

Software Requirements
Operating System : Developing Tool : Database : Windows 2000/XP Operating System. Visual Basic MS Access

Contents
Page No. 1. 2. 3. Introduction System Design Data Flow Diagram ER Diagram 4. 5. 6. 7. 8. 9. 10. 11. 12. Detailed Design Normalization Relational Schema Front End Design The Interface (screen shots) Reports Data Validation Conclusion Bibliography 1 2 5 5 7 9 10 11 13 14 18 23 24 25 Software Requirements Specification

INRODUCTION
This Student Database has been designed taking into account the practical needs to manage a Students data. Moreover, it provides security at product level as well as user level. Its design concentrates on 2 types of users: 1. Administrator 2. Students This Database follows a typical event flow seen in such a system. The database mainly is from the student point of view. Since the student is the center of the system, all the various records in the database revolve around the student activities. Some of the other independent categories of data include the library facility, fest, sports, cultural activities & alumni association. All such information helps one and all to know about the progress achieved by the institution. Every student can be given special attention by knowing his performance in the database. And if the organization is capable to put it on a LAN then it still adds more flexibility for the organization staff.

DATA STORAGE:
Student Profile: Student Details, Address, Admission Details, Dependent Details. Attendance Details: Total no of classes, No of classes attended by student for each subject. Internal & Examination Information: Takes Data for each of the 3 internals & Exam Details. Supports Data Management for finding: Student in each Department by URN. Internal Average Marks Scored. Attendance Shortage. Exam Result.

MANIPULATION OF DATABASE:
Addition of Student Profile. Addition of Department Details & its Corresponding Subjects. Modify or Delete Student Profile. Modify Attendance and Examination Results.

REPORT GENERATION:
List of Students in each Department. List of Attendance for each Student Department-wise. List of Examination Status for each Student Department-wise. So with respect to this we have taken up a small work here, wherein we have developed a database for Students Attendance & Examination Database that can hold the Institute in good stead.

Software Requirement Specification

Purpose:
Our Database is a store house of information regarding the various Student & the various attributes encapsulated in it. To maintain such a huge list of diverse data, the Institution cannot afford to maintain paper-work, as it is time consuming and has more chances to data loss and integrity loss. The huge amount of data can be made easily maintainable and accessible, by the use of computers. Commercial RDBMS like Oracle can ease the process of such an automation. Our Database Management project aims to provide computerized interface to all the data to be manipulated and stored, using Oracle and Visual Basic. The application provides for, 1. 2. 3. 4. Retrieval of any data based on particular criteria Storage of data, and its maintenance in a consistent manner Generation of customized reports based on particular criteria Easy to use, interface with menus and forms, for clearer navigability

The application also does the necessary data validation, so that redundant or, unnecessary duplicate data are prevented from creeping into the database. It also traps most of the common data entry errors. The Application differentiates between 2 types of users. One category is of Students who just want to get information about their individual details for attendance & Examination information. The administrative user is another category, who is authorized to add, delete and modify the database content. He can add New Department, corresponding Subjects. He can also enter Student info, simultaneously.

Software products used:

The following are the software that will be used in completing the project: ORACLE 8 (personal edition): As a back end to store the data. Oracle is chosen since it is robust and simple to use. Visual Basic 6.0: As the front end to create user friendly window interface. Visual basic provides comprehensive features that help in designing in detail.

The Overall High level Description:

Product Functions:
The following is a summary of the functions that the system is expected to perform: Provide separate access to individual Student and administrator such that only the administrator has the right to add, delete and modify the various services offered by the system. Provide the administrator with options to add as many Students, Departments, corresponding Subjects as required. The administrator must be provided with rights to modify the Student data store.. Provision to generate reports and make queries in any desired manner.

User Characteristics:
Any person with basic computer skills can make use of the product. The user should have only been briefed about the functionality of the system before he can start using the system.

Assumptions and Dependencies:

Apportioning of requirements:
The designers intend to upgrade the system to a LAN enabled multi user system besides providing connectivity to the internet for regular automatic updation of the data stored in the system.

Specific Requirements:
Functions:
The basic services that the Student Database System include Entry of New Students to the Department Entry of Attendance Information Entry of Examination Marks Provide individual and Department-wise reports. Update the student profile depending on Attendance & Exam Status. The system shall provide for password protected administrator access to add, delete & modify the basic services offered by the system.

The system shall provide for storing of Student personal details along with his Attendance & Examination marks. Reports: Individual Student report : Includes personal details of members. Department-wise report: Lists all the employees currently active User Interface & Security: Menu based Interface Floating Pop-up menu Customized Background Picture File based Encrypted Password Handling

Performance Specification:
The system is designed to be a stand alone, single user system. It is proposed to make the system multi user and network enabled in the future. The system is hence fast and efficient in terms of data retrieval. 95% of the transactions are completed within 2 seconds while the others may take approximately 5 seconds. (Above values vary from system to system.)

SYNOPSIS:

INVENTORY MANAGEMENT SYSTEM FOR MUSIC

INTRODUCTION: The project entitled INVENTORY MANAGEMENT SYSTEM FOR MUSIC STORE is developed as part of the VI Semester RDBMS package project for the partial fulfillment of the BCA degree. PROJECT: INVENTORY MANAGEMENT SYSTEM FOR MUSIC STORE is a software application maintaing the records related to purchase, sales, returns, stock updations, cash and bank flows and the reorder level of music store. OBJECTIVE: The main objective of the application is to automate the existing system of manually maintaing the records of the counter sales, purchases, reorder levels, Supplier and Customer monetary positions and other related transactions made at the counter. SCOPE: This application can be used by any music store to automate the process of manually maintaining the records related to the subject of maintaining the stock and liquid flows. PROBLEM DEFINITION: The transactions related to purchase, sale and returns are maintained manually at present along with maintaining the accounts of the customers and the suppliers.

All these are to be automated and an application is required to relate all of them relatively and logically so that the current system can be replaced and accepted without major changes and problems. The application should provide quick access to the records maintained and must reveal the important reviews about the business so that the growth can be easily compared and should provide with the various reports showing the related details so that the important decisions could be taken easily.

SOFTWARE REQUIREMENT SPECIFICATION:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS document itself states in precise and explicit language those functions and capabilities a software system must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

SRS are typically developed during the first stages of "Requirements Development," which is the initial product development phase in which information is gathered about what requirements are needed--and not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed. The National Bureau of Standards, IEEE (Standard No: 830-1984), and the U.S Department of Defense have all proposed candidate formats for software requirements specifications. The general structure is implemented with the related software application

INTRODUCTION: The project entitled INVENTORY MANAGEMENT SYSTEM FOR MUSIC STORE is developed as part of the VI Semester RDBMS package project for the partial fulfillment of the BCA degree. It is a software application maintaing the records related to all the transactions occurring at the counter of a shop. OBJECTIVE: The main objective is to maintain the inventory records of a generic shop which deals in musical tapes. To keep accounts of purchase and sales To know the current position of the debtors and creditors Bill generation Stock maintenance

SCOPE:

As this is generic software it can be used by a wide variety of outlets (Retailers and Wholesalers) to automate the process of manually maintaining the records related to the subject of maintaining the stock and cash flows. GOAL: The main goal of the application is to maintain the records of stock, billing, details of purchasers and sellers and their current financial positions with the company.

Banking Administration
SYNOPSIS
ABOUT THE BANK
The concerned bank serves in savings, current, fixed and recurring deposits. With the increase of the customers and investments in the bank, the bank needs to be computerized to provide better service to their customers.

ABOUT THE PROJECT

The bank offers the following four deposits: Fixed Deposit Savings Current Account Recurring Deposit

We aim at automating the transactions and maintaining of the related informations of the four deposits and we also aim at introducing ATM facility for the bank for providing better service to the customers.

FIXED DEPOSIT
Under this module only the fixed deposit is handled. There will be interest for which the board of directors will decide the rate. The tasks implemented here are: Create new fixed deposit accounts Enter the information of customer, the deposit Edit any customer information Calculate interest

SAVINGS
Under this module the savings account of the customers are handled. Interest will be calculated and the board of directors decides the rate. The tasks implemented here are: Create new accounts for customers Enter the deposit, withdrawal i.e., transaction and retrieval information Edit any customer information Calculated interest Generate daily reports, particular account numbers report, report of transaction between the two dates etc.

CURRENT ACCOUNT
Under this model current accounting is handled. No interest is awarded here. The tasks implemented here are: Create new accounts for customers Enter the deposit, withdraw i.e., transaction and retrieval information Edit new customer information Generate daily reports, particular account the two dates etc.

RECURRING DEPOSIT
Under this module only recurring deposit comes. There will be interest for which the board of directors will decide the rate. In this the customer for which he/she didnt pay the installments correctly should pay a penalty. The board of directors will fix this penalty rate. In this interface the user in charge will be able to: Create new recurring deposits Enter the information of customer, the deposit Edit any customer information Calculate interest

File Tracking System

For Medical Transcription Company

Content Slno. Description Page No 1. Software Requirement 3

Specification 2.

Hardware and Software 4

Requirement 3.

Functional Specification 5

4. 14 5.

Data Tables

Testing

19

6.

User Manual

22

Software Requirements Specification (SRS)

Abstract
This document fully and formally describes the requirements of the proposed said project system. It sets out the functional and non-functional requirements and includes a description of the user interface and documentation and training requirements.

Introduction

This project is prepared to help the client to maintain the day to day operations.

Purpose
The purpose of this document is to specify requirements and to give guidelines for the development of above said project. In particular it gives guidelines on how to prepare the above said project. This document is intended to be a practical guide for people who developing this software.

Scope Goal

Manual administrators control all the files. Once this project put in place this project will take care all the file transactions.

Provide an systematic method to transact the files over the network.

Hardware Requirements
Processor RAM Monitor Keyboard Mouse : : : Pentium III 400MHz and Above 128MB RAM 15 Color Monitor

Software Requirements
Operating System. Developing Tool Database : : : Windows 2000/XP Visual Basic MS Access

INTRODUCTION: The project entitled INVENTORY MANAGEMENT SYSTEM is developed as part of the VI Semester RDBMS package project for the partial fulfillment of the BCA degree. PROJECT: INVENTORY MANAGEMENT SYSTEM is a software application maintaing the records related to purchase, sales, returns, stock updations, cash and bank flows and the reorder level of music store. OBJECTIVE: The main objective of the application is to automate the existing system of manually maintaing the records of the counter sales, purchases, reorder levels, Supplier and Customer monetary positions and other related transactions made at the counter. SCOPE: This application can be used by any music store to automate the process of manually maintaining the records related to the subject of maintaining the stock and liquid flows. PROBLEM DEFINITION: The transactions related to purchase, sale and returns are maintained manually at present along with maintaining the accounts of the customers and the suppliers. All these are to be automated and an application is required to relate all of them relatively and logically so that the current system can be replaced and accepted without major changes and problems. The application should provide quick access to the records maintained and must reveal the important reviews about the business so that the growth can be easily compared and should provide with the various reports showing the related details so that the important decisions could be taken easily.

SOFTWARE REQUIREMENT SPECIFICATION:

An SRS is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. It's a two-way insurance policy that assures that both the client and the organization understand the other's requirements from that perspective at a given point in time. The SRS document itself states in precise and explicit language those functions and capabilities a software system must provide, as well as states any required constraints by which the system must abide. The SRS also functions as a blueprint for completing a project with as little cost growth as possible. The SRS is often referred to as the "parent" document because all subsequent project management documents, such as design specifications, statements of work, software architecture specifications, testing and validation plans, and documentation plans, are related to it. It's important to note that an SRS contains functional and nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. A well-designed, well-written SRS accomplishes four major goals:

It provides feedback to the customer. An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.

SRS are typically developed during the first stages of "Requirements Development," which is the initial product development phase in which

information is gathered about what requirements are needed--and not. This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current business environment. The actual specification, then, is written after the requirements have been gathered and analyzed. The National Bureau of Standards, IEEE (Standard No: 830-1984), and the U.S Department of Defense have all proposed candidate formats for software requirements specifications. The general structure is implemented with the related software application

INTRODUCTION: The project entitled INVENTORY MANAGEMENT SYSTEM is developed as part of the VI Semester RDBMS package project for the partial fulfillment of the BCA degree. It is a software application maintaing the records related to all the transactions occurring at the counter of a shop. OBJECTIVE: The main objective is to maintain the inventory records of a generic shop which deals in musical tapes. To keep accounts of purchase and sales To know the current position of the debtors and creditors Bill generation Stock maintenance

SCOPE: As this is generic software it can be used by a wide variety of outlets (Retailers and Wholesalers) to automate the process of manually maintaining the records related to the subject of maintaining the stock and cash flows. GOAL: The main goal of the application is to maintain the records of stock, billing, details of purchasers and sellers and their current financial positions with the company.

SYNOPSIS:

INTRODUCTION: The project entitled LIBRARY MANAGEMENT SYSTEM is developed as part of the VI Semester RDBMS package project for the partial fulfillment of the BE (Computer Science) degree. PROJECT: LIBRARY MANAGEMENT SYSTEM is a software application to maintain the records related to Book Purchase, Stock Maintenance, Book Search, Catalog, Book Issue, Book Returns, Fine Collection, and all necessary requirements for the Library to manage day to day operations.

OBJECTIVE: The main objective of the application is to automate the existing system of manually maintain the records of the Book Issue, Book Return from the student, Stock Maintenance, Catalog and Book Search to be computerized. So the Book Issue, Return, Searching will be faster.

SCOPE: This application can be used by any Library to automate the process of manually maintaining the records related to the subject of maintaining the stock and Book Issues.

PROBLEM DEFINITION:

The transactions related to Book Purchase, Book Issue and Book Returns are maintained manually at present along with maintaining the accounts of the Students and the Lecturers. All these are to be automated and an application is required to relate all of them relatively and logically so that the current system can be replaced and accepted without major changes and problems. The application should provide quick access to the records maintained and must reveal the important reviews about the business so that the growth can be easily compared and should provide with the various reports showing the related details so that the important decisions could be taken easily.

CONTENTS
Page No
1. Present system 2. Proposed system 3. Database Management system 3.1 3.2 3.3 4.1 4.2 4.3 5.1 Definition Difference between FMS and DBMS Advantages of DBMS Hardware requirement Software requirement Modules Back End Oracle 8 5.1.1 5.1.2 5.2 Codds Rule DDL, DML, TCL, DCL 4. 6. 8. 9. 10. 11. 14. 15. 17. 21. 23. 28. 29. 30. 31. 32. 32. 32. 36. 40. 47. 3. 1. 2.

4. System Analysis and design

5. Client Server Architecture

Front End-Visual Basic 6.0

6. Entity Relationship Diagram 7. Data Flow Diagram 8. Relational Schema 9. Normalization 9.1 9.2 9.3 10. Tables 11. Software Navigation 11.1 Forms 11.2 Reports 1NF 2NF 3NF

12. Conclusion 13. Bibliography

48. 49.

SYNOPSIS
KSTDC WELCOMES YOU TO THE WORLD OF HERITAGE
In the growing & competitive world it is becoming & absolutely necessary for any company to streamline all activities all the way stressing on quality perfection. Our project on TOURISM is carried out to monitor carefully & successfully the different aspects of any standard tourism department. India is a country of rich & varied cultural heritage. Indias amazing diversity offers you everything you want in a holiday. India is a valid kaleidoscope site of royal cities, golden beaches, misty mountain retreats , colorful people, rich cultures & festivals.

KARNATAKA: A TREASURE HOUSE OF THE MARVELLOUS

Its a state with many sparkling facts each very special. A charming, fascinating, historic, scenic, full of wonders waiting to be discovered thats Karnataka for you. The holiday seeker will find tranquility in karanataka pristine hill resorts or exotic beaches of karwar, mangalore & others. There are virgin forests where you can camp & enjoy the wildlife.

KSTDC OFFERS:
Karnataka state tourism development corporation offers you the quarantee of being looked after very well.

TEMPLE TOUR:
Karnataka is one of the state where the piligrims could find solace & spiritual routes in the glorious temples that dot the entire land. KSTDC covers the temples of horanadu, kalasa, srigeri, murdaeshwar, udupi, katil where are the wonderful, felonious temples where the tourists meets the vibrant future.

PLACES AROUND MYSORE:

Karnataka is a land worth touring where KSTDC operates the best guided tours in Karnataka. KSTDC provides the tourists the royal heritage of mysore. It covers srirangapatna, daria daulat, gumbos, ranganatha swamy temple, mysore palace, zoo, nanjungud where are the most beautiful & where most of the holiday seekers want to spend there vacation in the heaven of mysore.

SOUTH INDIA TOUR:

India holds a rich & various cultural heritage in which south India place an important role in monuments that breathe tales of valour from another era. KSTDC offers the visitors to view around thiruvanmallai, thiruallai, tanjore, srirangam, rameshwaram, kanyakumari , palani , kodaikonal. KSDTC uses state of art & comfortable fatigue free journey for you.

Package for PHOTO COLORLAB

Document

Introduction vStudios is leading color lab in the city. They have very advanced processing machines and lab. The main activities of the color lab is processing the film and make the prints. They are doing this business from last five years. To maintain the customers order properly they need a advance system which will track of all the orders and to make the billing.

Software Requirement Specification. The main objective of the project is to take the customer order based on the number of rolls they will give, advance taken and to make the billing. All this as one part program, In the other part they want to maintain all the employee details, their salary, payments etc.,

Functional Specification The proposed software must be simple and user friendly. In one form customer rolls received form to be maintained. Here customers rolls are collected for the printing. In the billing care should be taken to deduct the advance amount paid already. Also this should be very simple form. At one end it should shows all the orders received till they are billed.

Software Design Specification Design the software in a single form and provide all the options here only. The form should be very simple and user friendly. The result must be shown in the tabulated form. Also give provision to take the print out of this. Software requirement Front end : Visual basic 6.0 Backend : MS access Application software : Office 2000 Operating System : Windows 2000/XP Hardware Requirement Pentium Celeron 400MHz and above 64MB RAM and Above