SOFTWARE REQUIREMENTS SPECIFICATION (SRS) Ll INTRODUCTION The student management system can handle all the details about a student. the details include college details, course details, student personal details, and academic details etc, the student management system is an automated version of the manual student management system 1.1 PURPOSE The purpose of the system is to handle all the information of the student regarding admission, course registration, and other necessary school activities. Also, it will manage resources that were managed and handled by manpower previously. The main purpose of the SMS is to integrate distinct sections of the organization into a consistent manner so that complex functions can be handled smoothly by any technical or non-technical persons. 1.2 SCOPE The scope of the project includes the following: © Any college can use this system as it is not client-centric. * All admission and management-related work for students can be done using this system. * Deliver Electronic Workplace * Application support and maintenance after deployment. Online Student Information Management System is developed for general purpose and used to replace old paperwork systems and PUMS. OSIMS is to build upon theexisting information system PUMS to efficiently provide student information to teachers and school administration. This increase in efficiency of result making, providing results and giving feedback to students, and finally, publication and emailing student results. It provides a mechanism to edit the student information form which makes the system flexible. 1.3 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS OSIMS: Online Student Information Management System PUMS: Project Units Management System J2EE: Java? Platform Enterprise Edition ISP: Java Server Page SRS: Software Requirements Specification Os: Operating System2. OVERALL DESCRIPTION ‘The student management system allows authorized members to access the record of academically registered students. it can be used in various educational institutes across the globe and simplifies the working of institutes, 2.1. Product Perspective The various system tools that have been used in developing both the front end, back end and other tools of the project are discussed in this section. FRONT END HTML, JSP(Java Server Page), CSS, and JAVASCRIPT will be used to implement the front end. BACKEND ‘The backend will be implemented using PHP/MYSQL which is used to design the database3.0 SYSTEM FEATURES AND REQUIREMENTS 3.1 User Description There are three main users of the proposed system; the Admin, the student, and the teacher. Each user can perform several different functions during the use of the system. These functions were determined according to the design of the proposed system and user-friendly functions to make the system more effective and efficient. The table below summarizes the functions performed by each user. ACTORS FUNCTION + Log Inout + Add New Student SCHOOL ADMIN eee + Bait Student + Post task and any updates + Controls the whole system TEACHER + Post tasks and any updates + View complaints and recomendations + Log Inout + Add courses + Semester registration + Course registration + View and download result 3.1.1 User Interfaces ‘The OSIMS will have the following user-friendly and menu-driven interfaces ‘© Login: to allow the entry of only authorized users through a valid login Id and password. * School Details: to maintain school details.© Programme Details: to maintain programme details. © Scheme Details: to maintain scheme details of a programme * Faculty Details; to maintain the faculty details. 3.1.2. Hardware Interfaces * Screen resolution of at least 640 x 480 or above. © Support the printer (dot matrix, Deskjet, Laserlet) * Computer systems will be in the networked environment as it is a multi-user system. 3.1.3 Software Interfaces ‘*-MS-Windows Operating System * Microsoft Visual Basic 6.0 for designing front-end * MS SQL Server 2000 for backend iVIRONMENT(IDE): ECLIPSE 3.1.4 Memory Constraints At least 512 MB RAM and 500 MB space of hard disk will be required to run the software 3.2 Product Functions The ONSMS will allow a roles (School ss only to authorized users with specit administrator, teacher and Student). Depending upon the user’s role, he/she will be able to access only specific modules of the system A summary of major functions that the system will perform * Alogin facility for enabling only authorized access to the system. © School administrators will be able to add, modify or delete programme, school, scheme, paper and login information, * Students will be able to add/modify his/her details and register for papers to be studied in the current semester. * School administrator/teacher will be able to generate reports.3.2.1 User Characteristics © Qualification: At least matriculate and comfortable with English. © Experience: Should be well versed/informed about the registration process of the university. * Technical Experience: Elementary knowledge of computers 3.2.2. Constraints ‘There will only be one administrator. The delete operation is available only to the administrator. To reduce the complexity of the system, there is no check on the delete operation, Hence, the school administrator should be very carefull before deletion any record and he/she will be responsible for data consistency. 3.2.3. Assumptions and Dependencies © The login Id and password must be created by the y School administrator and communicated to the concerned user confidentially to avoid unauthorized access to the system * It is assumed that a student registering for the subsequent semester has been promoted to that semester by the university as per rules and has paid desired university fee. * Registration process will be open only for a specific duration. 3.3 SYSTEM REQUIREMENT Before creating any website or mobile App, it is necessary to visualize the layout, design, and all features intended to be incorporated. In addition, how users will interact with each page and icon and how the website/App should perform (behaviour, load time, etc.). Requirements are the necessary attributes in the system, a statement that identifies a capability, the characteristicor quality factor of the system to have value and utility to the users. Once the requirements are set, developers can initiate the other technical work including system design, development, testing, implementation, and operation. For any system, there are functional and non-functional requirements to be considered while determining the requirements of the system. The functional requirements are user “visible” features that are typically initiated by stakeholders of the system, such as generating reports, login, and signup. On the other hand, non-functional requirements are requirements that describe how the system will do what it is supposed to do, for example, security, reliability, and maintainability. 3.3.1 Functional Requirements A. Use Case Description ‘The steps that must be followed to log into the University Registration System. Actors * School Administrator © Teacher © Student School Admin * Create, edit and delete student accounts. * Create, edit and delete teacher accounts. * Post tasks or any updates for users (Teacher, and Student). * Store, edit, delete, calculate and print students’ grades. * Add Classes and courses and connect them with the subject’s teachers.* Tracking of all user activities Teacher * Enter Student's grades per Course/Subject * Contact students * Post tasks or any updates for users (Admin and Student) Student * View and print their grades/result * Semester/term registration * Adding/registering courses * Contact their teacher and school admin 3.3.2 Pre-Condition ‘The user must have a valid login Id and password. 3.3.3. Post Condition If the use case is successful, the actor is logged into the system. if not, the system state remains unchanged. 3.4 Basic Flow Starts when the actor wishes to login onto the URS ‘* The system requests that the actor specify the function he/she would like to perform (either Login, Change Password) * Once the actor provides the requested information, the sub-flow is executed. * If the actor selects “Login”, sub-flown sub-flow is executed If the actor selects “Change Password”, the Change Password sub-flow is executed, 3.5 NON-FUNCTIONAL REQUIREMENT SecurityEvery user has his account and only authorized users can access the system with a username and password. The passwords are encrypted using a PHP function shal (). Performance Easy tracking of records and updating can be done. Availability The system is available to users anytime. Anywhere, just need a PC and Internet Connection. Also the system work in multiple web browsers like (Chrome, Mozilla, Opera etc.) 3.6 Use case Diagram This part contains the analysis of the functional and non- functional requirements using use-case diagrams and use-case details. 1- Admin The functions that Admin can do after login, as shown in the figure below: - Add Teacher include (Modify/Delete) - Add Student include (Modify/Delete). - Add Class include (Modify/Delete) Contact with teachers, and students.‘Admin Student Modify/Delete Class ‘Modify/Delete Student The functions that Students can do after login, function as shown in the figure below: - View Personal Information. - Edit Personal Information - View/Print Courses Marks and grades. - View Personal Details. - Contact teachers and the school admin.Student View Personal information View /Print Course Grade Egit Personal Information3- Teacher The functions that Teacher can do after login, as shown in the figure below: - Enter Student's grades. - Modify or delete grades. - Contact students, and the school admin. Teacher3.6 SEQUENCE DIAGRAM Describes an Interaction by focusing on the sequence of Messages that are exchanged, along with their corresponding Occurrence Specifications on the Lifelines. ‘Admin ‘Student Teacher Clase ‘Add/Modity Student Send Messages ‘Send Messages ‘Adg/Modity Teacher ‘Ad Student Mark Send Messages ‘Ad Teacher to Claes ‘Add Courses to Class3.7 ACTIVITY DIAGRAM Describe dynamic aspects of the system. It is a flow chart to represent the flow from one activity to another activity. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another.3.7 CONCLUSION We had a description of the system and its users, and the functional and non-functional requirements then we talked about several tools such as the use case diagram, sequence diagram and activity diagram that have been used to analyze the interactive behavior of the activities.