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 onprime 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. 2. 3. 4. 5. 6. Click on New button to enter the new record Enter details in each box. To save the record click on Save Button Click on find button to see the find the required vehicle details Enter the vehicle number in the box and then click ok 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