Developed By

Raksha Infotech
No 826, 9th Main
RPC Layout, Vijayangar II Stage,
Bangalore - 40. Ph : 9243101428.
www.rakshainfotech.com
email : rakshainfotech@gmail.com
Contact us for more details
Content

Slno. Description Page No

1. Software Requirement Specification 3
2. Hardware and Software Requirement 6
3. Functional Specification 7
4. Functional Description 9
5. Software Design Specification 12
6. System Architecture Description 14
7. Feasibility Study 19
8. Data flow Diagram 24
9. Entity Relationship Diagram 27
10. Data Dictionary (Database Tables) 29
10. Normalization 31
11. Testing 32
12. User Manual 41
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.
An SRS is basically an organization's understanding (in writing) of a customer o
r potential
client's system requirements and dependencies at a particular point in time (usu
ally)
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 require
ments
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 cons
traints by
which the system must abide. The SRS also functions as a blueprint for completin
g 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, testin
g and
validation plans, and documentation plans, are related to it.
It's important to note that an SRS contains functional and nonfunctional require
ments
only; it doesn't offer design suggestions, possible solutions to technology or b
usiness
issues, or any other information other than what the development team understand
s 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 th

e
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 solutio
n 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 requi
rements
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 incl
ude
onsite visits, questionnaires, surveys, interviews, and perhaps a return-on-inve
stment
(ROI) analysis or needs analysis of the customer or client's current business
environment. The actual specification, then, is written after the requirements h
ave
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 requireme
nts
specifications. The general structure is implemented with the related software
application.
Introduction
This office is a Regional Transport Office a government organization.
The main activity of the RTO office is issuing the LL, DL, Vehicle
registration, Vehicle ownership transfer etc.., We proposed the
computerized method managing all the data. Because it brings
efficiency in the organization.
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
This is of pilot project prepared RTO office to maintain all the
records like issuing the LL, DL, Vehicle registration, Vehicle
ownership transfer etc. Once all these get computerized to work
efficiency of the employee will get increases.
Goal
The main goal of the project is to maintain the records of issuing
the LL, DL, Vehicle registration, Vehicle ownership transfer etc.
References
Existing System
At present all records are maintained manually.
Proposed System
In the proposed system will help them to manage day to day operation very smooth
ly
It is having different modules to pul fill the requirement of the organization.
Hardware and Software Requirements

Hardware Requirements
Processor : Pentium III 400MHz and Above
RAM : 128MB RAM
Monitor : 15 Color Monitor
Keyboard
Mouse
Software Requirements
Operating System. : Windows 2000/XP
Developing Tool : Visual Basic 6.0
Database : MS Access
Functional Specification

The Functional Specification is created after the Software Requirements Document

. It
provides more detail on selected items originally described in the Software
Requirements Document. Some software development organizations combine these
two documents into a single document.
The Functional Specification describes the features of the software product. It
describes the product's behavior as seen by an external observer, and contains t
he
technical information and data needed for the design. The Functional Specificati
on
defines what the functionality will be, but not how that functionality will be
implemented.
The software engineer uses the Functional Specification document to create a det
ailed
design document that explains in detail how the software will be designed and
developed. The detailed design work may further decompose and translate the
functional requirements into pseudocode, and from there into a computer module o
r
program.
The functional specification translates the Software Requirements Document into
a
technical description that:
· Ensures that the product feature requirements are correctly understood
before moving into the next step, the software design process.
· Clearly and unambiguously provides all the information necessary to
design the software.
Developing Functional Specification Contents
The Functional Specification contents are determined by the project manager, the
software developer, and typical end-users.
The end-users are important members of this team, because they will help ensure
the
software will meet the business and engineering needs of those who will use the
software. The project's user group is a good source for information and review.
For
guidance on drafting a functional specification, please see the links in the Bac
kground
Material and Examples section below.
Functional Specification Scope
The Functional Specification includes specific information about each functional
requirement of the software. The Functional Specification should describe, for e
ach
functional requirement:
· Purpose - What the function is intended to accomplish.
·
Input - What inputs will be accepted, in what format the inputs arrive, sources
for the inputs, and other input characteristics.
·
Process -The steps to be performed, algorithms, formulas, or techniques to be
used. Software implementation details are not included, however.
·
Output - Desired outcomes such as the output form (e.g. report layout), the
destination of the output, output volume and timing, error handling procedures,
and units of measure.
Usability items need to be included in the Functional Specification. These are f
eatures
that ensure user friendliness of the software. Examples include clear error mess
ages,
input range checking as soon as entries are made, and order of choices and scree
ns
corresponding to user preferences.
Functional Description

The problem under study is being divided into several modules/functions discuss
ed
below to understand the approach to the solution in the broader way:
Main Screen and login Screen
Vehicle Registration From
Learner s Licence Registration Form
Driving Licence Registration Form
Change of Address Form
Tax Collection Form
Vehicle Renewal Form
Change of ownership form
External Interfaces
The interfaces in this section are specified by documenting: the name and descri
ption
of each item, source or input, destination or output, ranges, accuracy and toler
ances,
units of measure, timing, display formats and organization, and data formats.
· User Interfaces: Describes all major forms, screens, or web pages, including
any complex dialog boxes. This is usually best done via simulated, non-functioni
ng
screen shots (such as PowerPoint slides), and may take the form of a separate
document.
The navigation flow of the windows, menus, and options is described, along with
the
expected content of each window. Examples of items included are screen resolutio
ns,
color scheme, primary font type and size. Discussion also includes how input
validation will be done, and how data will be protected from accidental changes.
Specific items are described for each screen such as input fields, control butto
ns,
sizing options, and menus.
· Hardware Interfaces: Describes the equipment needed to run the software,
and also other output or input devices such as printers or handheld devices.
Pentium III or above, 128MB RAM or above
· Windows Operating system.
Performance
Program is written such way that it gives ultimate performance for user. And it
is a
single user. So there is not much complexity in the project. Normally database w
ill
grow slowly. If the performance is not up to the mark, and it take long time the
n,
Open MS Access database run repair database tool.
Design Constraints
Examples of constraints that affect software design choices are items such as me
mory
constraints involving minimum and maximum RAM and hard disk space, and
limitations arising from hardware, software or communications standards.
Attributes
· Security: Project level security is set. User need to login when they start the
program, option is also provided to create the additional user and also the user
level
security. Presently user level security is not set but can be implemented with f
ew
modifications.
·
Reliability, Availability, Maintainability: It is very user friendly software,
Data is secured, There is not much maintenance. Project can be upgraded as
per the requirement step by step.
·
Configuration and Compatibility: Describes requirements such as those
connected with individual customization or operation in specific computing
environments.
·
Installation: Provided with the set files. User can easily install to the system
.
Describes the planned method for installation: done by the user independently,
done by customer company internal IT services, done by an external contractor.
Specifies the handling of such items as data transfer from prior releases, and
the presence of software elements from prior releases.
·
Usability: Describes items that will ensure the user-friendliness of the
software. Examples include error messages that direct the user to a solution,
input range checking as soon as entries are made, and order of choices and
screens corresponding to user preferences. More ideas on software usability
elements are found in:
Software Design Specification

The Software Design Specification (SDS) given in this outline are guidelines to
the
contents of your SDS. The document should present the conceptual and detailed
technical design of the software/module that you are developing.
Introduction
Purpose of this Document
This Software Design Specification (SDS) document contains a statement of the
design of the above title project. In an SDS, the designers are supposed to prov
ide an
unambiguous design of the product. The design should contain an explanation of a
way to carry out each of the product specifications written in the Software
Requirements Specification (SRS). The design then serves as a guide to the
developers who write the code and actually create the product. The SDS discusses
how the program is separated into modules, how the modules interact with each
other, and how users see the program. The SDS also looks into several design
considerations, including design tradeoffs and code reusability.
Scope of the Development Project
The project Tool is a new project which creates an interactive and easy program.
The
package serve to the end user customers. Eventually, we hope to reach a broader
audience.
Definitions, Acronyms, and Abbreviations
· ActionScript - ActionScript is a tool used to write the code that controls the
actions in animated Flash presentations.
· Asp.net Microsoft web based project development tool
· C, C++ - The names of two object oriented programming languages commonly
used in industry.
· CEO - Chief Executive Officer.
· Form is object holder in Visual Basic Language. Defines single screen.
· HTML - Hypertext Markup Language. A language used to create Web

documents.
· IIS Internet Information Server 5.0
· Internet Explorer Microsoft Internet Browser version 6.0
· MS Access Microsoft developed Database Program.
· Oracle Oracle Corporation RDBMS database program.
· SDS - Software Design Specification document.
· SQL Server Microsoft RDBMS software.
· SRS - Software Requirements Specification document.
· Visual Basic 6.0 Programming Language
· VB.net Microsoft dot net Programming tool
System architecture description

Document Outline
Here is the outline of the proposed template for software design specifications.
Please
note that many parts of the document may be extracted automatically from other
sources and/or may be contained in other, smaller documents. What follows is jus
t
one suggested outline format to use when attempting to present the architecture
and
design of the entire system as one single document. This by no means implies tha
t it
literally is a single document (that would not be my personal preference):
Major Screens
Main Screen and login Screen
Vehicle Registration From
Learner s Licence Registration Form
Driving Licence Registration Form
Change of Address Form
Tax Collection Form
Vehicle Renewal Form
Change of ownership form
Detailed description of components

Main Screen and login Screen

This is main login screen employees as to login from this point based
on their provision corresponding form will be opened.
Vehicle Registration From
This form is used to register the vehicle. All new vehicles has to
registered in the RTO offices. Here separate forms are provided to
register the two wheeler, Light Motor Vehicle, heavy Motor vehicle and
special application vehicles. All information about the vehicle will be
entered here.
Learner s Licence Registration Form
This form is used to issue the learner s licence, when a candidate apply
for the learner s licence this form will filled. Based on the text marks its
result will be declared. If he/she passes then learner s licence will be
issued to the candidate.
Driving Licence Registration Form
After obtaining the Learner s licence after a month they need appear
for driving licence here they have to take the test. If they pass test
then driving licence will issued to them. There is a separate driving
licence will issued for two wheeler and four wheeler.
Change of Address Form
This form is used enter the change of address in Driving licence. They
have to pay nominal fee for this service. After changing address a
separate driving licence will issued t o the candidate.
Tax Collection Form
This form is used to enter the details of the tax paid for the vehicle.
Generally they collect life time tax for the vehicle. This is the one time
tax vehicle owner has to pay. The receipt will be given to the owner. All
necessary fields has to be taken into consideration.
Vehicle Renewal Form
This for is used to make the renewal of the vehicle. All four wheelers
has to get the renewal time to time. This form used for the same
purpose.
Change of ownership form
When people sell their vehicle to the other people this form is used to
make change of ownership.
Software Environment

The proposed system is developed using Visual Basic as the front end and MS Acce
ss as
the back end.
Visual Basic
A very user friendly very robust application to build the customized application
s. It can
support various other platforms also.
· It encompasses object oriented programming that creates and use the object as a
fundamental part of development process.
· Object is a basic element, which helps to build the application.
· Standard database formats for many applications are in built.
· Database creation is very simple and is done in a GUI environment.
· Modifications can be easily done to the created database.
A design description of an object in Visual Basic has a protocol description th
at
establishes the interface of an object by defining each event that the object ca
n receive
and the related operation that the object can perform when the particular event
is fired.
It has an implementation description that shows implementation details for each
operation implied by an event that is processed to an object. That implementatio
n details
about the objects private part i.e., the internal details about the data structu
re and
procedural, functional details that describe the operations.
FEATURES
The following are the various features of Visual Basic that made to select this
software for
the project.
IMPROVED RELIABILITY:
The Visual Basic takes the core achievements originally made in Windows 2000 and
brings
them to new levels. With advanced ways of monitoring the health of running appli
cations,
as well as isolating applications from each other, applications built using the
Visual Basic
stay up-and-running longer than ever before.
Developer Productivity:
Developers of all backgrounds are finding that they can rapidly get up to speed
on the
Visual Basic. The intuitiveness of the programming model, the amount of code alr
eady
provided in the class libraries, and the amount of work that the Visual Basic ha
ndles
behind the scenes in areas such as memory management have enabled Visual Basic
developers to reap huge productivity gains.
Powerful, Granular Security:
The code access security technology in the Visual Basic was designed for today's
Internet
environments. The Visual Basic can collect evidence about the origin and author
of an
application. The Visual Basic run-time environment can then combine that evidenc
e with
administrator-set or default security policies to make fine-grained decisions ab
out
whether to run that application or enable it to access a particular resource. It
can even
"negotiate" with the application, for example, denying it the permission to writ
e to a
protected directory and enabling the application to choose whether it will run,
given that it
has been denied that permission.
Support for Other Programming Languages:
The Visual Basic supports the integration of over other programming languages in
a way
unimagined previously, enabling developers to choose the right programming langu
age
for the task at hand. All programming languages target a single, extensive, and
extensible set of class libraries. Components written in different languages sup
ported by
the Visual Basic can interact seamlessly, with no COM plumbing required.
FLEXIBLE DATA ACCESS:
The Visual Basic technology for interacting with data, ADO (ActiveX Data Object)
, is
designed for today's Web-based style of data access. Using ADO, developers have
the
option of working with a platform-neutral, XML-based cache of the requested data
,
instead of directly manipulating the database. This approach to data access free
s up
database connections and results in significantly greater scalability.
MS Access

Microsoft Access is a relational database management system from Microsoft,

packaged with Microsoft Office Professional which combines the relational Micros
oft Jet
Database Engine with a graphical user interface. It can use data stored in Acces
s/Jet,
SQL Server, Oracle, or any ODBC-compliant data container. Skilled software
developers and data architects use it to develop powerful, complex applications.
Relatively unskilled programmers and non-programmer "power users" can use it to
build simple applications without having to deal with features they don't unders
tand.
It supports substantial object-oriented (OO) techniques but falls short of being
a fully
OO development tool.
Microsoft Access was also the name of a communications program from Microsoft,
meant to compete with ProComm and other programs. It proved a failure and was
dropped. Years later they reused the name for their database software.
Few Terms
These words are used often in Access so you will want to become familiar with th
em
before using the program and this tutorial.

A database is a collection of related information.

An object is a competition in the database such as a table, query, form, or
macro.
A table is a grouping of related data organized in fields (columns) and records
(rows) on a datasheet. By using a common field in two tables, the data can be
combined. Many tables can be stored in a single database.
A field is a column on a datasheet and defines a data type for a set of values i
n
a table. For a mailing list table might include fields for first name, last name
,
address, city, state, zip code, and telephone number.
A record in a row on a datasheet and is a set of values defined by fields. In a
mailing list table, each record would contain the data for one person as
specified by the intersecting fields.
Design View provides the tools for creating fields in a table.
Datasheet View allows you to update, edit, and delete in formation from a
table.
Queries
Queries select records from one or more tables in a database so they can be view
ed,
analyzed, and sorted on a common datasheet. The resulting collection of records,
called a dynaset (short for dynamic subset), is saved as a database object and c
an
therefore be easily used in the future. The query will be updated whenever the o
riginal
tables are updated. Types of queries are select queries that extract data from t
ables
based on specified values, find duplicate queries that display records with dupl
icate
values for one or more of the specified fields, and find unmatched queries displ
ay
records from one table that do not have corresponding values in a second table.
Table Relationships
To prevent the duplication of information in a database by repeating fields in m
ore
than one table, table relationships can be established to link fields of tables
together.
Feasibility Study

Feasibility study is a test of a system proposal according to its workability, i

mpact on the
organization, ability to meet user needs, and effective use of resources. The fe
asibility
study is to serve as a decision document; it must answer the following questions
.
1) What are the user's demonstrable needs?
2) Is the problem worth solving?
3) How can the problem be solved?
All the successful projects are not necessarily the biggest but rather those tha
t truly meet
the user expectations. Three key considerations involved in the feasibility anal
ysis are
economic, operational and technical.
· Economic Feasibility:
Economic feasibility is the most frequently used method for evaluating the effec
tiveness
of a candidate system. The procedure is to determine the savings and the benefit
s from
the candidate system and compare with costs. If the benefits outweigh the costs
then it is
decided to go ahead with the
projects. Otherwise, further justification or alterations in the proposed system
will have to
be made if it is to have a chance of being approved. This is an on-going effort
that
improves in accuracy at each phase of the system life cycle.
· Operational Feasibility:
People are resistant to change and computers have been known to facilitate chang
e. An
estimate should be made of how strong a reaction of the user staff is likely to
have an
impact towards the development of a computer system. It is common knowledge that
computer installations have a lot to do with turnovers, transfers, retaining and
changes to
employee job status. Therefore it's understandable that the production of the ca
ndidate
system requires special effort to educate and train the staff on the new way of
doing the
job. But since ultimately the introduction of a new system will only reduce the
staff's
workload, they may have no objection to install a computerized system, and of co
urse will
be eager to extend their cooperation.
· Behavioral Feasibility:
It relates human behavior in the organization and political aspects. Here we foc
us on:
1) What changes will be brought with the system
2) What organizational structures are disturbed
3) What new skills will be required
Do the existing members have these skills? If not can they be trained in due cou
rse of
time. It also includes social and managerial aspects that is whether the propose
d project
will be acceptable to the customer and the management, along with the determinat
ion of
whether the proposed project considers Act, Status as well as pending Legislatio
ns as a
part of the legal feasibility
· Technical Feasibility:
Technical feasibility centers on the existing system and to what extent it can s
upport the
proposed system. This involves financial considerations to accommodate technical
enhancements. If the budget is a serious constraint, then the project is judged
not
feasible. Now considering the proposed system, our client has been maintaining t
he
records manually at the present. So he has to purchase new computer systems for
the
automation of the concern. The owner having realized the advantages, benefits an
d
economic feasibility of the new system is ready to afford the expenses for the s
atisfaction
of all the hardware and software requirements. Therefore the project, in questio
n, is
technically feasible as well.
· Conclusion:
This system developed for Jain Group of Institutions aims at maintaining the rec
ords of
the camps that have been held, dates of the camp, number of patients treated, nu
mber of
people operated upon, number of patients given free spectacles, money spent, tra
nsport
details, number of doctors who attended the camp, details of the camp and follow
up
dates.
It increases the efficiency of the voluntary camp and also reduces the workload,
as there
is no need to maintain the records manually.
This project is designed using very carefully and a lot of thought has been put
into the
making of the system. It has been developed using VB 6.0 an approved front-end t
ool that
is a very efficient graphical user interface.
This system automates the entire process and will surely serve its purpose for m
any years
to come.
System Design

A computer procedure is a series of operations designed to manipulate data to pr

oduce
outputs from a computer system. The procedure may be a single program or a serie
s of
programs. The detail design of the computer procedure follows acceptance by
management of an outline design proposal. The aim now is to design procedures at
lower
levels of detail, which will define the detailed steps to be taken to produce th
e specified
computer output. When complete, these procedure definitions together with data
specifications are organized for programmers from which the required programs ca
n be
written.
Design Tools:
Various tools are being used by system analysis to specify computer procedures.
Not
all of them are used here to design this project. Some of the important tools th
at have
been made use of are:
1. Entity relationship Diagram.
2. Input design.
3. Output Design.
4. Database Design.
Input design:
Input design is a part of overall system design, which requires very careful
attention. Often the collection of input data is the most expensive process of t
he system.
In terms of both the equipment used and the number of people involved, it is the
point of
most contact for the users with the computer system; and it is prone to error. I
f data going
into the system is incorrect, then the processing and output will magnify their
errors.
One of the early activities of input design is to determine the nature of the in
put data. This
is done partially in logical system design but it now needs to be made more expl
icit.
Error avoidance and Detection:
Every effort must be made to ensure that input data remains accurate from the st
age at
which it is recorded and documented to the stage at which the customer accepts i
t. While
every effort is made to avoid errors during the preparation of input data, a pro
portion of
errors are likely to be present.
The user is free from the anxiety of keeping the uniqueness of the primary key s
ince the
system itself generates the primary key for the user.
As soon as the user keys erroneous data in, the system just will not accept the
data and
provides appropriate messages.
Data validation:
Computer input procedures must also be designed to detect errors in the data at
a lower
level of detail which is beyond the capability of the control procedures. These
are
combined with the design of the input process itself.
The validation procedure must be designed to check each record, data item, field
against certain criteria specified by the system analyst or the programmer.
Output design:
The specification of user requirements is the starting point for the appraisal a
nd the
detailed physical design must be done in the light of this and with continuing u
ser
involvement. The normal procedure is to design the outputs in detail first and t
hen to work
back to the inputs. The outputs can be in the form of operational documents, len
gthy
reports, and replies to queries or summarizing graphs.
Outputs from computer systems are required primarily to provide a permanent copy
of
the results for later consultation. Any data item not yet defined must be identi
fied and
recorded before output design can proceed. There is often a need at output to pr
ovide
totals at various levels. It is not always desirable to print or display data as
it is held on a
computer. The system analyst must ensure whether the form in which it is stored
in the
system is suitable for the output.
In proposed system the users have been provided with many outputs in the form of
messages and alerts so as to help the user enter the correct data.
Reports:
Reports enhance the application programmer's effort to output the formatted data
in a
manner practical for the user. This also helps to create hard copy of the valid
information.
ARCHITECTURAL DESIGN
Architectural design represents the structure of data and program components
that are required to build a computer based system. It considers the architectur
al style
that a system will take, the structure and properties of the component that cons
titute the
system, and the inter relationships that occur among all architectural component
s of a
system.
Although a software engineer can design both data and architecture, the job is
often allocated to specialists when large, complex systems are to be built. A da
tabase or a
data warehouse designer creates the data architecture of a system. The system ar
chitect
selects an appropriate architectural style for the requirements derived during s
ystem
engineering and software requirements analysis.
Architectural design begins with data design and then proceeds to the derivation
of
one or more representations of the architectural structural of the system. Alter
native
architectural style or patterns are analyzed to derive the structure that is bes
t suited to
customer requirements and quality attributes. Once an alternative has been selec
ted, the
architecture is elaborated using an architectural design method.
An architectural model encompassing data architecture and program structure is
created during architectural design. In addition, component properties and relat
ionships
are described.
Data Flow Diagram

A Dataflow Diagram also known as Bubble Chart is used to clarify System requiremen
ts
and identifying major transformations that all become programs in System Design
SYMBOLS

Data Source/Destination
Process
Data Storage
Flow of data
Data Flow Diagram
ENTITY RELATIONSHIP DIAGRAM

Entity

Relationship

Attribute

Key Attribute
Entity Relationship Diagram
Data Dictionary

COAMain
DLNo
oname
fname
padd1
padd2
padd3
ppin
tadd1
tadd2
tadd3
tpin

CVMain
RegNo
oname
fname
padd1
padd2
padd3
ppin
Name
PName
tadd1
tadd2
tadd3
tpin

DLMain
DLNo
LLNo
oname
fname
padd1
padd2
padd3
ppin
tadd1
tadd2
tadd3
tpin
edate
idate
vdate
IBY
RNO
RAmt

LLMain
LLNo
oname
fname
padd1
padd2
padd3
ppin
tadd1
tadd2
tadd3
tpin
ed
Aincome
Imark
bgroup
testtype
MaxMarks

Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text

Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text

Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Date
Date
Date
Text
Text
Text

Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
Text
MVMain
vno Text
oname Text
fname Text
padd1 Text
padd2 Text
padd3 Text
ppin Text
tadd1 Text
tadd2 Text
tadd3 Text
tpin Text
cov Text
mname Text
btype Text
yom Text
nocy Text
cno Text
eno Text
rdate Date

TaxMain
RegNo Text
oname Text
fname Text
padd1 Text
padd2 Text
padd3 Text
ppin Text
regdate Date
myear Text
hpower Text
rno Text
ramt Text

TWMain
vno Text
oname Text
fname Text
padd1 Text
padd2 Text
padd3 Text
ppin Text
tadd1 Text
tadd2 Text
tadd3 Text
tpin Text
cov Text
mname Text
btype Text
yom Text
nocy Text
cno Text
eno Text
rdate Date
VRMain
RegNo Text
oname Text
fname Text
padd1 Text
padd2 Text
padd3 Text
ppin Text
regdate Date
myear Text
Normalization

DEFINITION
In relational database design, the process of organizing data to minimize redund
ancy is
called normalization. Normalization usually involves dividing a database into tw
o or more
tables and defining relationships between the tables. The objective is to isolat
e data so
that additions, deletions, and modifications of a field can be made in just one
table and
then propagated through the rest of the database via the defined relationships.
There are
three main normal forms, each with increasing levels of normalization:
1. First Normal Form
First Normal Form (1NF): Every cell I the table must have only one value i.e. it
should not
have multiple values.
2. Second Normal Form
Second Normal Form (2NF): All non-key attributes must be fully functionally depe
ndent
on the primary key and not just the part of the key.
3. Third Normal Form
Third Normal Form (3NF): The database must be in the second normal form and no n
on-
prime attribute should be transitively dependent on the primary key.
4. Fourth Normal Form
It deals with multiple valued dependencies
5. Fifth Normal Form
It deals with joined dependencies
6. Boyce Codd Normal Form
It states that no inverse partial dependencies should exist in the database
The Inventory Management System of a Music Store is developed using the second
normal form where the primary key of one table acts as a foreign of another tabl
e and all
the attributes of the table are dependent on the primary key and not the part of
the key.
Testing

Introduction
This document is intended to be used throughout the coding and testing phases of
the
project. It outlines the procedures used for testing and verification of the cod
e. The
document also describes the integration procedures and the order in which module
s
will be coded, and describes the test procedures and results of testing.
This section deals with the details of the classes of tests which must be conduc
ted to
validate the functions, performance, and the constraints. This is achieved basic
ally by
the means of testing which plays a vital role in the development of the software
. The
various low level testing which can be grouped on a broader sense are discussed
as
below:
There are three levels of testing:
1. Unit Testing -- Each module will be tested separately to ensure that it is
working before being combined with other modules.
2. Integration Testing -- Related modules will be integrated and tested
together before being placed into the system.
3. System Testing -- The entire system will be tested together after
integration is complete. System testing includes function, acceptance,
installation and regression testing. System testing will involve some beta
testing by the client.
Notes
All testing has been carried out using some sample data.
Each section in the remainder of this document has lists of test criteria that m
ust be
satisfied for the system to have passed that section of testing. In front of the
each
criterial test Passed or Failed is written.
Unit Testing
The purpose of unit testing is to uncover errors in the smallest software unit -
- the
routine. Each routine will be tested individually using black box-oriented tests
. The
programmer of each module will design a set of test cases for that module and en
sure
that the module is fully tested. Important or complex routines will also be test
ed by at
least one other person.
The following Forms are tested for the functionality
Main Screen and login Screen
Vehicle Registration From
Learner s Licence Registration Form
Driving Licence Registration Form
Change of Address Form
Tax Collection Form
Vehicle Renewal Form
Change of ownership form
Integration Testing
This section describes the integration strategy and procedures for the system. I
t gives
the order in which modules will be developed and how they will be integrated. It
also
describes the specific tests that will be performed on integrated sets of module
s.
Note: It is important that each module be thoroughly tested as a unit before bei
ng
integrated with other modules.
Integration testing of unit tested modules is necessary to ensure that:
· modules interface correctly with each other;
· one module does not have inadvertent, undesirable effects on another
module;
· submodules (routines) combine to produce the desired functions of the
major module;
· interfaces to, and use of global data structures are consistent.
Tested the Stock form correct updation

System Testing
Functional Requirements Testing
The functionality tests should be performed by the application representatives a
nd
treat the whole system as a black box using the actual applications or middlewar
e.
The aim of these tests is to verify the overall functionality of the system.
This will be performed by a section by section walkthrough of the SRS functional
requirements section. All functional requirements in the SRS must be fulfilled.
Beta Testing
Method
This will be performed by the client, and by potential users of the system at th
e
Bureau of Meteorology. Users will be given a copy of the system to try out. Any
problems with the system will be reported back to the group.

Beta Testing

To help us achieve the best possible result with our project, we have decided to
get as
much input as possible from potential users of our system.
Bugs.
If unexpected events happen while using project,
Alterations.
If there is anything missing from the system, that you would like to see there,
we

would also like to know about it. Most likely we will not be able to implement t
he
changes to the current system (due to time restraints), but when the full system
is
written next year, it will most likely be present.

· All Comments... Can be sent to us in various ways.

Please include your name and email address in any correspondence.

Results
Comments received from the customers:
Alpha testing - prototype 2 of system
Performance and Stress Testing
A set of tests have been developed for performance and stress testing. Performan
ce
tests will ensure that the system responds in a reasonable time to user input (a
s
defined in the SRS). The aim of stress testing is to try to break the program by
giving
it abnormal or extreme input quantity, frequency or volume.

Performance testing will be performed at the client's site after installation. A

ccording
to the SRS:
The system must respond to all reports within 10 seconds on an Pentium IV comput
er
with a load average less than 1.

Performance criteria satisfied.

Stress testing with extreme and abnormal input cases has been been performed
where necessary on individual routines in the Unit Testing section.
Stress testing satisfied.
Acceptance Testing
Acceptance testing consists of a suite of tests to be performed in the presence
of the
client before he accepts the system. It will consist of the function tests, perf
ormance
tests (at the client's site), a walk-through of the user manual and the final
demonstration.
Function tests accepted.
Performance tests accepted.
User manual walkthrough accepted. Will be held performed along with
Installation Testing.
Final demonstration accepted.
Installation Testing
Installation tests will check the installation and configuration procedure as we
ll as any

missing dependencies.
Installation tests test the installation and configuration procedures. These tes
ts are a
set of scripts that automatically download all necessary packages and install th
em.

Acceptance testing will be repeated after installation of the system at the Cust
omer
Place. This is to ensure that the system works correctly in the Customer Place.
Note: System has not been installed for the client yet. Will be installed this w
eek.
Some specific points that also need to be tested are:

1. Directory paths for data and help files are set up correctly and can be found
by
the system.
2. Check for necessary third party controls.
3. All IDL library functions can be found by the system.
4. All fonts for the text tool can be found and loaded -- beta testing uncovered
some problems loading some fonts.
5. Check Printer drivers are installed properly.
Regression Testing
The selective retesting of a software system that has been modified to ensure th
at
any bugs have been fixed and that no other previously working functions have fai
led
as a result of the reparations and that newly added features have not created
problems with previous versions of the software. Also referred to as verificatio
n
testing, regression testing is initiated after a programmer has attempted to fix
a
recognized problem or has added source code to a program that may have
inadvertently introduced errors. It is a quality control measure to ensure that
the
newly modified code still complies with its specified requirements and that unmo
dified
code has not been affected by the maintenance activity.
Regression testing was not usually necesary, because most of the errors detected
were very localised, and did not affect other functions in an adverse manner.
User Manual
And
Screen Shots
Main Screen and login Screen
Vehicle Registration From

1
2
3 6 7
5
84
Follow the below steps enter the Data
1. Click on New button to enter the new record
2. Enter details in each box.
3. To save the record click on Save Button
4. Click on find button to see the find the required vehicle details
5. Enter the vehicle number in the box and then click ok
6. If any changes need to be done then make changes and then click Modify button
7. If you want to delete the record then click on Delete button
8. To close the form click on Close button.
The same method is applicable to all other forms.
Learner s Licence Registration Form
Driving Licence Registration Form
Change of Address Form
Tax Collection Form
Vehicle Renewal Form
Change of ownership form