Practical-3

Aim : Prepare SRS document for current semester project using example shown in Rajib mall Book. Software required: Microsoft office Project 2007 Hardware required: Computer Knowledge required: - SRS Theory:

1.0 Introduction The Online Result management system is the service on the internet provided by the University for the Students & faculty Staffs & other persons. Under this web-site not only students can see their results but it will be useful to college members & faculties also. By using this, the faculty members can upload the marks directly on the web-site & central examiner can verify and approve it. The result analysis for the educational dean and other Administrative person will become very easy & user-friendly by this software. 1.1 Purpose The system is designed to provide the user(Students/Faculties,etc..) a mode of informing about the result electronically. Without using this type of software the university/college manages the result database manually & inform the students by doing lots of paperwork. It seems the effort wasted & wasting of time in this era. Besides this, our aim is to provide e-services that offers flexibility through the adding the college, generate the result, assigning the grade, upload the marks, modify the marks, generate the result graph, etc. 1.2 Scope The software contains: A home page which contains sign in, sign-up boxes, adding the college & university facility & different tabs like latest news updates, feedback & suggestions, reviews, photo-gallery, etc A sign up facilities is logically divided into 3 categories like student, Faculty member, Administrative person/Central Examiner. Facility for adding the college in university Facility for generating the result grade from the marks Facility for uploading the internal & practical marks by particular faculty Facility for approving or modify the marks by the Central Examiner. Facility to generate the semester wise result graph or subject wise graph Facility to generate result analysis. Facility to inform the students by e-mail alerts.
1

Inputs: User Details New college details Services Result related details

Outputs: Total Result with subject wise Grade & credits User sign up form Authority to modify the marks(only on Administrative log in) Processing: Verification of user information with the database Identify the user category from user s charusat-mail id Store the information of newly signed up user. Marks to Grade conversion & calculate the credits Generating the result analysis graph Definition, Acronyms, and Abbreviations Code-ignighter: It is one type of php which has been used for coding purpose. HTML (Hyper Text Markup Language): It is used to create static web pages. DB(Database): It is a database management system that provides a flexible and efficient database platform to raise a strong "on demand business applications HTTP (Hyper Text Transfer Protocol): It is a transaction oriented client/ server protocol between a web browser and a web server. XML (Extensible Markup Language): It is a Markup language that was designed to transport and store data. Ajax (Asynchronous Java Script and XML): It is a technique used in java script to create dynamic web pages. Web 2.0: It is commonly associated with web applications which facilitate interactive information sharing, interoperability, user-cantered design and collaboration on the World Wide Web. References Technologies to be used Code-ignighter with php Ajax: Asynchronous Java Script and XML. XML: Extension Markup Language. Web 2.0: RSS Feed 2.0.
2

1.3

1.4 1.5

MySQL: for database. 2.0 Overall Description 2.1 Product Perspective 2.2 Software Interface Front End Client: Code-ignighter 2.0 Web Server: Apache-wamp server.

Data Base Server: SQL Server Back End: MySQL command line client & MySQL Workbench 5.2 Graph-Editor: Y-ED graph editor 3.8 & Microsoft VISIO 2.3 Hardware Interface Client Side: minimum Pentium processor with 512 mb RAM & 4GB HDD Server Side: i3 processor with 3 GB RAM & 320GB HDD Product/Software Function 2.4.1 Software Context: The software is aimed to provide facilities to the student for informing about their results. And to make the result related administrative work very easy & fast.

2.4

2.5

User Characteristics 2.5.1. User profiles Students: Students can only see the results of their internal & external exams. They can see only their personal result. They cant retrieve another persons result Faculty Members: They can retrieve the category wise marks & upload the internal marks only. They are may be class-coordinator or subject coordinator. they are not allow to modify the external marks. Central Examiner: They have the main access to the database. This type of user has rights of modify the internal & External marks also. After the verification of this person, Result will be declare for students. Administrative Person: They are not allow to modify internal or external marks but they have access to know any students results & they can generate the result analysis graph. 2.6 Constraints 2.6.1 Major Constraints: 1.User who dont have charusat mail id will not able to access this software. 2. If any user get fail in final exam then the Backlog procedure module cant be count by this software. 3. For Backlog students, after each semester the new database is required.

3.0 Specific Requiremen 3.1 Functional Requirements

1. User Login activity l 1 Student Login 1.1.1 Student Sign-up 1.1.: Student Login 1.1.3 Student Feedback 1.1.4 Application Pomo for Reassessment 1.2 Faculty Login 1.2.1 Faculty Sign-up 1.2.2 Faculty Sign-in 1.3 Administrative Login 1.3.1 Administrative sign-up 1.3.: Administrative login 2. Generating Result 2.1 Generating Result on Student Logon INPUT: select the option for internal and practical result & external result OUTPUT: Display the list box for choosing category 2.1.1 Display the result for internal and practical exams INPUT: Student id & Password OUTPUT: Result of particular student with their internal & practical marks DESCRIPTION: applications itself compare the login with the database & identify that whether it is Student/Faculty/Administrative person 2.1.2 Display the result for external exams INPUT: Student id & Password OUTPUT: Result of particular student with their external marks & grade DESORPTION: application itself compare the login id with the database & Identify that whether it is Student/Faculty/Administrative person 2.2 Generates Result on faculty login INPUT: asking for choosing option for branch/subject/semester wise external result or particular students external Result. OUTPUT: show the result with appropriate option 2.2.1 Generate the branch/subject/ year wise external result INPUT: asking to choose the appropriate branch, subject and semester OUTPUT: generate the list of students result as per selected option 2.2.2 Generate the particular student's external result INPUT: asking for student id number OUTPUT: generate the result of this student 2.2.3 Internal & Practical Results 2.2.3.1 View the internal / practical Result 2.2.3.2 Upload the internal / practical marks 2.3 Generates Result on Administrative login 2.3.1 View. & Verify the internal & practical marks uploaded by faculties INPUT: asking to choose the appropriate branch and semester. OUTPUT: generate the student result as per selected option with 'Verify' &

'Modify' button. DESORPTION: when admin will choose the proper option then result will be shown with two buttons, When 'Verify' will be pressed then permission will be assigned to student & can see the result

3.2 Non-functional requirements

Software Interface Front End Client: Code-igniter 2.0 Web Server: Apache-wamp server. Data Base Server: SQL Server Back End: MySQL command line client &MySQL Workbench 5.2 Graph-Editor: Y-ED graph editor 3.8& Microsoft VISIO

Hardware Interface Client Side: minimum Pentium processor with 512 MB RAM& 4GB HDD Server Side: i3 processor with 3 GB RAM & 320GB HDD

3.3 Interfaces 3.3.1 Specify: The System is made in PHP and every user must be connected with the server for daily transaction. The System will interact with the User through GUI. So, User can easily operate with the System.

3.3.1 Hardware Interfaces Printer Server Connection.

3.3.2 Software Interfaces Specify the use of other required software and interfaces with other application systems. For each required software include: Name: MY SQL Server, Visual-Studio Source: Windows 2000/XP bootable CD.

The System is made in PHP The user must have the PHP and MYSQL to have communication with administrator.

3.3.3 Communications Interfaces The System is Web based and interaction between users and administrators take place through Web Application. 3.3.4 Memory Constraints The Memory Constraints for running the project is: RAM: 256 MB Hard Disk: 80 GB

4. Change Management Process

The Change management Process is carried out by communication i.e. meeting. Changes to SRS or any other change in the requirement is carried out by written application.

5. Supporting Information

The supporting information makes the SRS easier to use. It includes: Table of Contents Index Appendices

The Appendices are not always considered part of the actual requirements specification and are not always necessary. They may include: (a) Sample I/O formats, descriptions of cost analysis studies, results of user surveys (b) Supporting or background information that can help the readers of the SRS (c) A description of the problems to be solved by the software (d) Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements When Appendices are included, the SRS should explicitly state whether or not the Appendices are to be considered part of the requirements.