1. INTRODUCTION 1.

1 PURPOSE The main objective of this document is to illustrate the requirments of the project education guidance system .The document gives the detailed description of both , functionak abd non functional requirmentsproposed by the client. The document is developed after a number of consultations with the client and considering the complete requirement specifications of the given project . the final product of the team will be meeting the requirements of this document .

1.2 DOCUMENT CONVENTIONS

The following are the list of conventions and acronyms used in this document and the project as well Client :intened users of the software SQL : structured Queery Language ;used to retrieve information from a database SQL SERVER: A server used to store data in an organized format PHP: Hypertext preprocessor(or Personal Home Page): A Web Page formatted on the server and delivered to the browser . Layer : Represents section of the project User Interface Layer : The section of the assignment referring to what the user interacts with directly Application Logic Layer: The section of the assignment referring to the web server . this is where all computations are completed .

 Data Storage Layer : The section of the assignment referring to where all data is recorded Data flow diagram : It shows the dataflow between the entites . Use Case : A broad level diagram of the project showing a basic overview Boolean: A true /false notation Interface : Something used to communicate across different mediums Unique Key : used to differentiate entries in a database

1.5 REFERENCES <List any other documents or web addresses to which this SRS refers . These may include user interface style guides,contracts,standards ,system requirements specifications ,use case documents or a vision and scope document,provide enough information so that the reader could access a copy of each reference ,including college name ,id,course name .>

2.0 OVERALL DESCRIPTION Education Guidance Organization maintains college and course details in India. Relation College Have 5 Attributes. 1. 2. 3. 4. 5. COLLEGE CODE COLLEGE NAME ADDRESS RANK TYPE OF COLLEGE

Relation Course have 2 Attributes. 1. COURSE CODE 2. COURSE NAME ORGANIZATION Provides college information for users and if he knows only college code then he/she can get address of that college. It also provides TOP College in India. It provides All Course details in India. Also provides when user search for course available in college by giving college code as input. Also provides when user search for college having course by giving course code as input. It provides education news that is Entrance exam details.

2.2

USER CLASSES AND CHARACTERSTICS

Usually the website is visited by students for getting more information about colleges and courses 2.3 OPERATING ENVIRONMENT The product will be operating in any platform environment,also it will be compatible with IE 6.0. Most of the features will be compatible with the Mozilla firefox & Opera 7.0 or higher version . The only requirement to use this online product would be the internet connection . 2.4 DESIGN AND IMPLEMENTATION CONSTRAINTS Here product is developed using php . the database is MYSQL Server . The product is accomplished with no login facility so that specific function is available to specific member . 2.5 USER DOCUMENTAION The product will include user manual.The user manual will include product overview ,complete configuration of the used software (such as MYSQL server ), technical details ,backup procedure and contact information which will include mail address ,,there will no help for the product at this moment ,the product will be compatible with the intenet explorer 6.0 or higher,the database will be created in the MySQL of php 2.6 ASSUMPTIONS AND DEPENDENCIES The product needs the following third party product : MySQL SERVER to store the data PHP to develop the product

2.7 .FUNCTIONAL REQUIREMETNS This section gives the list of functional and non-functional requirement which are applicable to the education guidance system . 2.8 INTERFACE REQUIRMENTS This section describes how the software interfaces with the users for input and output 2.9 USER INTERFACE Describes how this product interfaces with the user . GUI Describes the graphicl interface if present ,This secton should include a set of screen dumps or mockups to illustrate the user interface features. 1.Description The user interface must be customizable by the administrator. 2.Criticality This issue is essential to the overall system. All the modules provided with the software must fit into this graphical user interface and accomplish to the standard defined. 3.Techincal issues In order to satisfy this requirement the design should be simple and all the different interfaces should follow a standard template. There will be the possibility of changing colors and images, plus switching between interfaces with the minimum impact for the users.

4.Risks To reduce the circumstances under which this requirement might not able to be satisfied, all the designers must have been developed web sites previously and they must be awar of restriction and cross browsers implementations before starting the designing. I order to reduce the probability of this occurrence the entire design team will be trained in basic html development and macromedia fireworks, this tool will be used instead of Photoshop. 5.Dependencies with other requirements All user interface should be able to interact with te user management module and a part of the interface must be dedicated to the login/logout module. 4.NON FUNCTIONAL REQUIREMENTS 4.1 USER INTERFACES 4.2 HARDWARE INTRFACES Server Side: *Operating system: Windows 7,Windows xp *Processor: Pentium 3.0 Ghz or higher *RAM: 256 Mb or more 4.3 SOFTWARE INTERFACE *Database: Mysql server *Application: PHP (Personal Home Page)

*Web server: IIS(Internet Information Services (IIS) is a powerful web server that provides a highly reliable, manageable, and scalable web application infrastructure) 4.4 INTERFACES The customer must connection with a internet provider. 5.OTHER NONFUNCTIONAL REQUIREMENTS 5.1 PERFORMANCE REQUIREMENTS The prposed system that we are going to develop will be used as the chief performance system within the different campuses of the university which interact with the university staff and students. Therefore, it is expected that the database would perform functionally all the requirements that are specified by the university. 5.2 SAFETY REQUIREMENTS

The database may get crashed at any certain time due to virus or operating system failure. Therefore, it is required to take the database backup. 5.3 SECURITY REQUIREMENTS

We are going to develop a secured database for the university. There are different categories of users namely administrator, library staff and members of the library. Depending upon the category of user the access rights are decided. It means if the user is an administrator then he can be able to modify the data, delete, append etc., All other users other than library staff only have the rights to retrieve the information about database. Software Quality

Attributes: The Quality of the database is maintained in such a way so that it can be very user friendly to all the users of the database. 5.4 HARDWARE CONSTRAINTS The system requires a database in order to store persistent data. The database should have backup capabilities. 5.5 SOFTWARE CONSTRAINTS The development of the system will be constrained by the availability of required software such as web servers, database and development tools. The availability of these tools will be governed by the library itself. The most recent versions of software development tools may not be installed at the library. 5.6 DESIGN CONSTRAINTS The system must be designed to allow web usability. That is, the system must be designed in such a way that will be easy to use and visible on most of the browsers. 6.OTHER REQUIREMENTS APPENDIX A: GLOSSARY <Define all the terms necessary to properly interpret the SRS including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS> APPENDIX B: ANALYSIS MODELS

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state transition diagrams, or entityrelationship diagrams> APPENDIX C:ISSUES LIST <This is a dynamic list of the open requirements issues that remain to be TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like>