SOFTWARE REQUIREMENT SPECIFICATION FEEDBACK EVALUATION SYSTEM PREPARED FOR Professor Abhishek Vaish, Indian Institute of Information Technology, Allahabad PREPARED BY Shivam Agarwal (IIT2017110) Tushaar Kumar (IIT2017129) Pranav Jhawar(IIT2017141) Heimal Shukla(IIT2017104) Prashik Raut(IIT2017137) TABLE OF CONTENTS 1. P URPOSE 1.1. Product Purpose 1.2. Document Purpose 1.3. Intended Audience and Reading Suggestions 1.4. Product Scope 1.5. References 2. OVERALL DESCRIPTION 2.1. Product Perspective 2.2. Product Functions 2.3. Use Classes and Characteristics 2.4. Operating Environment 2.5. Design and Implementation Constraints 2.6. Assumption and Dependencies 3. EXTERNAL INTERFACE REQUIREMENTS 3.1. User Interfaces 3.2. Hardware Interfaces 3.3. Software Interfaces 3.4. Communication Interfaces 4. SYSTEM FEATURES 5. OTHER NON-FUNCTIONAL REQUIREMENTS 5.1. Performance Requirements 5.2. Safety and Security Requirements 6. PROJECT TIMELINE INTRODUCTION 1. P URPOSE The project aims at collecting feedback of faculties of particular courses from students of an institute and then evaluating their performance based on various parameters. By using this technology we can provide fast feedback about the college lecturers by students on time. The webapp can be used by students to register the feedback, faculties to view their feedback, admins to evaluate and analyse the collected feedback. 2. I NTENDED AUDIENCE AND READING SUGGESTIONS This Software Requirements document is intended for: 1. Developers who can review project’s capabilities and more easily understand where their efforts should be targeted to improve or add more features to it (design and code the application – it sets the guidelines for future development). 2. Project testers can use this document as a base for their testing strategy as some bugs are easier to find using a requirements document. This way testing becomes more methodically organized. 3. End users of this application who wish to read about what this project can do. 3. P ROJECT SCOPE In today's world, to improve upon a task , one has to constantly learn from the mistakes made which is done by collecting and evaluating feedback on the task. The major drawback of collecting feedback manually is that it is quite difficult to keep all the feedbacks organised and thereafter analyse it manually. It takes a lot of time and effort to collect and analyse feedback of thousands of people. The purpose of the Feedback Evaluation system is to help ease the process of collecting, storing and organizing feedback online. The system provides an easier and quicker way to give a rating to the college staff. Students can rate their respective faculty members according to their knowledge, teaching style, discipline and punctuality at any time from any place. User interfaces could help students find the information that is in accordance with their interests by personalizing the application. Above all, we hope to provide a comfortable user experience along with the ease of feedback evaluation. OVERALL DESCRIPTION EXISTING SYSTEM Coming to the existing system the feedback is done by manual process. In the existing system students can give feedback about the lecturers by using paper and pen. After giving feedback by every student Papers are collected by the Hod’s and calculate the overall grade for each lecturer. After that those all grade report is viewed by the principal which is given by the Hod’s. Hence estimating the performance of lecturers and giving counseling to college staff. So, the existing system is carries more time to do a piece of work for this reason. The online system feedback is implemented. This is the major advantage of the existing system for giving feedback about the Lecturers and viewing report of lecturers. PROPOSED SYSTEM Here we aimed to design an online web application for issuing the feedback about the lecturers by students, this is named as Faculty feedback system. Faculty feedback System to provide feedback in an easy and quick manner to the college lecturers . So we call it as Faculty Feedback System which delivers via the student staff interface as online system which acting as a Service Provider by using this technology we can make fast feedback about the staff by students on time to head of departments as they referred in online system. This project has four kinds of users Student, Staff, Hod’s, and Admin. The student can give feedback in online system provided by college staff. Students and can give feedback about the lecturers. These feedback reports were checked by the Hod’s. He can view overall grades and view the grades obtained to the lecturers and give this report to the principal and he can give counseling to the college staffs compared to the manual system, online system is very simple to use and also understand. 2.2 PRODUCT FUNCTIONS This system included four modulus which were described below in details: • Admin module • Student module • Faculty module • HOD module The core functionalities that are to be included in the system are the follows:ADMIN MODULE • Can insert/update/delete/new student (But, not Feedback). • Can insert/update/delete/new staff member. • View the final feedback report STUDENT MODULE • Give feedback to their respective department staff members based on various parameters - Teaching Style - Punctuality - Understanding of Subjects - Doubt solving • Can give suggestions,comments/Message to the respective staff members FACULTY MODULE • Can view their only own comments/message and Rating Criteria given by students. • Can view total evaluated feedback. HOD MODULE • Can view result their respective department. • Can give Suggestion to Staff member or student according to the particular comments. • Submit feedback result to the Principal. 2.3.1 USE CASE DIAGRAM Use case diagram consists of use cases and actors and shows the Interaction between the use cases and actors. Use cases are the functions that are to be performed in the module. An actor could be the end user of the system or the external system. 2.3.2 CLASS DIAGRAM The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application. 2.3.2 ER DIAGRAM 2.4 DESIGN AND IMPLEMENTATION CONSTRAINT Our WebApp Has Following Constraints:1. The product is Web-based only. 2. The product is dependent on relational database to store login information / student / faculty information. 3. The WebApp will require active internet connection . 2.5 ASSUMPTIONS AND DEPENDENCIES The assumptions are : 1. The system should be user-friendly so that it is easy to use for the users. 2. The coding should be error free. 3. The information of all users (Student , Staff and Admin) must be stored in a database that is accessible by the app. 4. Users may access from any device that has internet browsing capabilities and an internet connection. 5.The system should have more storage capacity and provide fast access to the database. 6. End users of our software are assumed to have a basic level of knowledge about our product. The dependencies are:1. The specific hardware and software using which the product will be run. 2. On the basis of the listing requirements and specification the project will be developed and run. 3. The end users should have proper understanding of the product . 4. The information of all the users must be stored in a database that is accessible by the Webapp system. 2.6 REFERENCES References of knowledge used in our project are as follows: 1. NodeJS documentation. 2. Geeks for Geeks. 3. SRS Documentation. EXTERNAL INTERFACE REQUIREMENTS There are many types of interfaces as supported in this software : 1. User interfaces 2. Hardware interfaces 3. Software interfaces 4. Communication interfaces 3.1 USER INTERFACE The user will see a login page on a larger system where he will be asked to enter his username and password to go to respective page. There different users can select different functionalities provided by our WebApp like :View Courses, select faculty to give feedback, viewing feedback etc. All this will be done according to access rights given to respective user like only. An admin can add another student and faculty etc. 3.3 SOFTWARE REQUIREMENTS HTML,CSS and Javascript will be used for designing and developing the FeedBack Evaluation System. We use the same authentication protocol as used in the earlier version of the existing software where the user will first be prompted to enter his username and password. Upon the successful validation of his credentials, he will land up on his respective page whether it is student, admin or college staff. The inference engine enables the WebApp system to draw deductions from the information provided by the user. Oracle DB will be used to store the admin, student and staff database, using the Javascript(NodeJS) for backend. Javascript, HTML and CSS will be used for frontend development. To run this project on various platforms we need some hardware and software to support this Project. 3.3.1 HARDWARE SPECIFICATION Processor: Dual core RAM: 512 mb Memory: 10 GB 3.3.2 SOFTWARE SPECIFICATION Technologies: HTML, CSS, NodeJS Database: Oracle DB Language: Javascript IDE: Visual Studio Code 3.4 COMMUNICATION INTERFACE This system is a WebApp based application; therefore network connection with TCP/IP protocol is necessary. SYSTEM FEATURES 1. The User(Student, teacher or admin) will be required to sign up , if not registered. The user should fill details including name, email, password etc, . 2. The User will be required to login if already registered. 3. The user will be authenticated based on password entered. 4. The user will be directed to the main page based on whether he/she is a student, faculty or admin. The portal has 3 sections, one for each of Student, Faculty and Admin. STUDENT: ● Login using unique user id and password. ● Can view the courses in which student is enrolled. ● Can select a faculty teaching a particular course and submit his feedback. ● Can view an overall leaderboard and also specific to a particular course. FACULTY: ● Can view the feedback report of all the courses currently under the faculty. ● Won’t be able to see the identity of students providing feedback. ADMIN: ● Can register, update and delete students and faculties in the system. ● Can view student specific feedback for a faculty. ● Can view an overall leaderboard and also specific to a particular course. ● Can send mails to students asking to register the feedback. 5. The user will logout after the work is done, and the database will be updated. OTHER NONFUNCTIONAL REQUIREMENTS 5.1 PERFORMANCE REQUIREMENTS 1. Product will be based on local server. 2. Product will take initial load time. 3. Performance will depend upon hardware components. 4. Performance will depend upon tables in Relational Database. 5. Performance will depend upon data set size. 6. The password verification should be accurate and quick. 5.2 SAFETY AND SECURITY REQUIREMENTS 1. Source code developed for this system shall be maintained in configuration management tool. 2. Whole system should be secure; only admin can access all data. 3. This system will use HTTPS because this protocol is more secure. 4. This System will use secured POS system. 5.There is no special protection built into this system other than to provide the user with a uthentication access to login to the expert System software. PROJECT TIMELINE Design - Waterfall Model The w aterfall model is a sequential design process in which progress is seen as flowing steadily downwards (like a w aterfall) through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. PHASES TASK COMPLETED EXPECTED PERIOD OF PROGRESS Phase 1 SRS Documentation 25 Sept-1 Sept ‘19 WebD 25 Sept-15 Oct ‘19 Phase 2 Designing 15 Oct-17 Oct ‘19 Phase 3 Modelling 17 Oct-19 Oct ‘19 Phase 4 Coding 21 Oct-30 Oct ‘19 Phase 5 Testing 1 Nov-5 Nov ‘19 Phase 6 Deployment 10 Nov ‘19 Phase 7 Feedback/Maintenance 11 Nov-31 Nov ‘19