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. E​XTERNAL 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