CHAPTER 1: INTRODUCTION

1.1 Introduction about the Company

Brahma computers is a world class producer of advanced measuring, monitoring,

controlling and testing web applications. Individuals with varied educational and
technical skills use these applications in a wide range. All over the world covering
a wide ground in the field of IT solution provider. It emerged in the year of 2011
and gains a landslide success within this short span of time.
Brahma computers is being moved with te motto to provide the best and innovative
solutions to our clients, customers and business. At Brahma Computers we mean
business and we ensure our team of professional and dedicated technology and
support resources deliver as per your expectations.

1.2 Problem Statement

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 teacher and
calculate the overall grade for each lecturer. After that those all grade report is
viewed by the principal which is given by the teacher or head of department.
Hence estimating the performance of lecturers and giving counseling to college
staff. So, the existing system carries more time to do a piece of work for this
reason. In brief following system has following drawbacks which are covered in
proposed system:-

 Lack of Security
 More Man Power
 Time Consuming
 Needs Manual calculations
 No direct role for higher officials.

1.3 Proposed Solution

The ‘Feedback System’ Approaches all about institutional practices and processes
that are taken into consideration, the student’s concerns of the level of the
knowledge they receive. The Student Feedback System is a management
information system for education establishments to manage student data. An
Online Student Feedback System is an automatic feedback generation system that
provides the proper feedback to the teachers as per the categories like always,
poor, usually, very often, sometimes.
The aim of proposed system is to develop a system of improved facilities. The
proposed system can overcome all the limitations of the existing system. Proposed
System covers following drawbacks of existing system:-
 Security of data
 Ensure data accuracy
 Proper control of higher officials
 Minimize manual data entry
 Minimum time required for various processing
 Greater efficiency
 Better service
 User friendliness and interactive
 Minimum time required

1.4 Deliverables
Online feedback system is web based system which provides a way to allow
students to give feedback for staff online to improve their teaching. Students are
required to give feedback using one standard feedback form. In our project, the
security is also maintain by result of feedback is only visible to authentic user. This
project also includes time portal. This system helps teachers to improve the
performance by analyzing the feedback given by students.
 CHAPTER 2: PROJECT DESCRIPTION
2.1 System Interfaces

System interface are logically divided into Hardware interface& Software interface
:

 Web Browser :
· Internet Explorer / Mozilla / Firefox/ Google Chrome

 Operating System :-
· Minimum Windows XP

 Hardware Interfaces

Server Side
 Computer platform minimum P4
 800 MHz of Processor
 128 MB of RAM
 Networking
 Minimum 500mb of free space
 Keyboard & Mouse
Client Side
 Computer platform minimum P4
 800 MHz of processor
 128MB RAM
 Minimum 2 GB of Free Space
 Should be connected network (server)
 Keyboard & Mouse

Software Interfaces
 Language : C# ,Html
 Front End : ASP.NET
 Back End : Sql Server 2005
2.2 System Specifications

1. HARDWARE REQUIREMENTS:
Processor: Dual core

RAM: 512 MB

Memory: 10 GB 2.3.2

2. SOFTWARE REQUIREMENTS:
Technologies: HTML, C#

Database: MySql

Language: ASP.NET

IDE: Dreamviewer, Visual Basic, Notepad++

2.3 Communication Interfaces

The HTTP protocol will be used to facilitate communications between the client
and server.

2.4 Methodology and Tools used

2.4.1 Requirement Phase

The requirement phase aims to capture the functional requirements. The basic
idea with the requirement models is to capture right from the start all the functional
requirements of the system from a user perspective. This is accomplished in
requirements model. Here we describe how a potential user will use the system.
This model is often developed in close participation with end users and orderers.
In order to create the requirement model following steps are used:
 Actors and use cases
The first transformation made is from requirement specification to the requirement
model. The requirement model consists of:
 A use case model
 Interface Description
 A problem Domain model
The usecase model uses actors and use cases. These concepts are an aid to
defining what exits outside the systems(actors) and what should be performed by
the system(use cases).

ACTOR

Use Case

Figure: The use case model consists of actors and use cases.

The actors represent what interacts with the system. They represent everything
that needs to exchange information with the system. For ‘student feedback
system’ we have actors as admin, teachers, students and HOD. They are called
as actors because they represent a certain role that a user can play. Whereas a
system may have a number of users. The Users is the actual person who uses
the system. For example, for our system we may have the actors Teacher and
HOD. Jim Smith is a user who sometimes acts as a teacher for other department
and sometimes acts as HOD of the department.
An instance of an actor carries out a number of different operations on the system.
When a user uses the system, he/she will perform behaviorally related sequence
of transactions in a dialogue with the system. We call such a special sequence a
use case. In the Student feedback system we can identify a number of use cases.
Let us use the actors as a starting point. The Student can login to the system
answers the questionnaires and add comments. So login, answer questionnaires
and comments are three use cases associated to the student. Similarly, use cases
associated with the admin will be login/logout, add questionnaires, update record,
view record and view feedback result.
Hence the use case model is described by a number of actors and use cases. For
the use cases, we make detailed descriptions. When the system is in operation,
instances are created from the descriptions in this model.
The interface Description is typically created for a general end user through an
, which enables access to and interaction with the underlying system/software.
The interface Description specify what the user interface will look like when the
use cases are performed. Here, a prototype of the user interface is a perfect tool.
For instance, when a student login to the Student feedback system the window
appears is the interface for the student. The Student feedback system has
different kinds of interface. There is the login panel, questionnaires window,
feedback window etc.
A problem domain object model is used to give a conceptual picture and better
understanding of the system, objects are used to represent occurrences in
problem domain.This basically defines entity objects. To communicate with the
potential users, it is often appropriate to sketch a logical and surveyable problem
domain model of the system. It consists objects that have a counterpart in the
problem domain under consideration, and serve to support for the development
of the requirements model. Problem domain model contains:
 Object Name
 Logical Attributes
 Static instance association
 Dynamic instance association
 Inheritance operations.

 Use Case driven Design

As we design in this way, the system model will be use case driven. When we
wish to change the system behavior, we remodel the appropriate actor and use
case. As we have traceability through all models, we will be able to modify the
system from new requirements. We ask the users what they want to change and
see directly where these changes should be made in the other models.

The use case model is used when developing all other models i.e. The use case
model will control the formation of all other models. It is developed in cooperation
with the domain object model and it may, in cases where the domain object model
is worked into a detailed object model,be expressed in terms of domain objects.

2.4.2 Design Phase

When the requirement model is developed and approved by the system users or
orderers, we can start to develop the actual system. This starts with development
of the analysis model. This model aims to structure the system independently of
the actual implementation environment. This means that we focus on the logical
structure of the system. It is here that we define the stable, robust and maintainable
structure that is also extensible.
In the information space of this model, our aim is to capture information, behavior
and presentation.
The information dimension specifies the information held in the system, both short
term and long term. Along this dimension, we describe the system’s internal state.
In the Behavior dimension we specify the behavior which the system will adopt.
Here, we specify when and how the system will change state.
The presentation dimension provides the details for presenting the system to the
outside world.
The analysis model is built by specifying objects in this information space. The
object types used in the analysis model are entity objects, interface objects and
control objects. The entity object models information in the system that should
be held for a longer time, and should typically survive a use case. The interface
object models behavior and information that is dependent on the interface to the
system. The control object model functionality that is not naturally tied to any other
object.
In the ‘student feedback system’ each of the concrete actors, needs its own
interface object to the system. Each actor needs the login panel to enter the details
and access the system. So, login will serve as the basic interface object for the
student feedback system. Now, we have the means to handle the information
about the students and their feedback. Since it is very essential information for the
system, we model it with an entity object anyway. We therefore identify an entity
object student and other sub entity object feedback. Since a specific user may act
a teacher or HOD, so we must keep the information according to the role of the
user. So, the entity object Faculty will be used to store the information about the
various faculties. Apart from We have report and questions as sub entity objects,
where report will store the overall grading of the feedback and questions will store
the questions used for feedback of students. Control objects are the controllers of
the system which acts a glue which unite the other objects so that they form a use
case. So, in our feedback system validId, logggedIn, feedbackGiven are some
of the control objects which controls the working of entity and interface objects.

2.4.3 Development Phase

In the development phase, we construct the system using both the

analysis model and the requirement model. First, we create a design
model that is refinement and formalization of the analysis model. The
initial work when developing the design model is to adapt to the actual
implementation environment. Design Model is the formalization of
analysis space, where we adapt the analysis model so that it fits into our
implementation environment. Our goal is to refine analysis model until it
is easy to write the source code from it. Analysis model is the basis of the
design model. We use the concept of block to describe the intension how
the code should be produced. The blocks are the design objects and they
are drawn as the rectangles. One block normally aims to implement one
analysis object. To describe the communication between the blocks we
use stimuli. A stimulus is sent from one block to another to trigger an
execution in that block. This execution may send new stimuli to other
 blocks. To describe a sequence of stimuli, we use interaction diagrams.
As a base to these interaction diagrams weuse the use case model again.
Thus we describe in detail, for each use case, how and which stimuli will
be sent and in what order.

Figure : INTERACTION DIAGRAM OF THE STUDENT FEEDBACK SYSTEM WITH OPERATIONS IN THE
PARTICIPATING BLOCKS.

2.4.4 Implementation Phase

Implementation is the process of translating the detailed design into

code. When this is done by a single individual, the process is relatively
well understood. But, most real-life products today are too large to be
implemented by one programmer within the given time constraints.
Instead, the product is implemented by a team. The implementation
model consists of annotated source code. The information space is one
that the programming language uses. The base of the implementation is
the design model. Here we have described each block and also have
 described the behavior of what is expected behind this interface. The
implementation included things like type conversion, keying, error
handling, versioning and such like. Typically, one block will map onto
about 1-5 classes.
The adaptation to the programming language will be made according to
the specialization of the construction process to the selected language.
The specialization of the programming language describes how we
translate the terms used in the design into the terms and properties in the
implementation language. Following points are kept in mind while
creating the implementation model:-
 Choosing the programming language
In ‘STUDENT FEEDBACK SYSTEM’ we have used ASP.NET as the front
end programming language. ASP.NET is a web application framework
developed and marketed by Microsoft to allow programmers to build
dynamic web sites. It allows you to use a full featured programming
language such as C# or VB.NET to build web applications easily. ASP.NET
works on top of the HTTP protocol, and uses the HTTP commands and
policies to set a browser-to-server bilateral communication and
cooperation.ASP.NET is a part of Microsoft .Net platform. ASP.NET
applications are compiled codes, written using the extensible and reusable
components or objects present in .Net framework. These codes can use
the entire hierarchy of classes in .Net framework.

 Code Reuse
One way we can reuse code in ASP.NET is to put your script checking
code into a new class. Add a new class to the project we're working on,
and name it. Add your script checking code as a static method to this new
class. Also, In our "code behind" file, we can just call the static method we
have created, such as NewClass.ScriptAttackChecker(parameters) and
simply use that part of code in our file.

 Integration
One approach to integration of the product is to code and test each code
artifact separately. We make artifacts of each block and stubs for each
calling of inherited block in this technique.

 Good programming practice.

a. Use of consistent and meaningful variable names.
It is counterproductive for a programmer to give names to variables that
are meaningful to only that programmer; within the context of software
 engineering, the term meaningful variable names means “meaningful
from the viewpoint of future maintenance programmers.”
b. Issue of self documenting code.
This implication means that their variable names are chosen so
carefully and their code crafted so exquisitely that there is no need for
comments. The way to avoid the future problem that may occur in
postdelivery maintenance phase is to insist that every variable name
should be explained at the beginning of the code artifact, in the
prologue comments.
c. Use of Parameters
There are very few genuine constants, that is, variables whose values
never change. All such apparent constants should be treated as
parameters. If a value should change for any reason, this change can
be implemented quickly and effectively.
d. Nested if statements
Another problem with the if-if construct is that nesting if statements too
deeply leads to code that can be diffi cult to read. As a rule of thumb, if
statements nested to a depth greater than three is poor programming
practice and should be avoided.

 Coding Standards
Many projects and organizations have coding standard concerning how the
source code should be written. The purpose of these standards is to obtain
a uniform source code that not only facilitates understanding and reading ,
but also achieves portability between different environments.

 The implementation workflow

The aim of the implementation workflow is to implement the target software
product in the selected implementation language. A large software product
is partitioned into smaller subsystems, which are then implemented in
parallel by coding teams. The subsystems, in turn, consist of code artifacts.

2.4.5 Testing Phase

Testing phase is the last phase and testing model is the last model developed in the
system development. It describes simple stated, the result of testing. The
fundamental concepts in testing are mainly the test specification and the test
result.
Initially at lower levels object modules and blocks are tested.They are tested by
designers.
Lower subsystem levels are then tested. The integration testing is done at this
level.
 Testing Levels Used:

Unit Testing
A level of the software testing process where individual units of a software
are tested. The purpose is to validate that each unit of the software performs
as designed.
Integration Testing
A level of the software testing process where individual units are combined
and tested as a group. The purpose of this level of testing is to expose faults
in the interaction between integrated units.
System Testing
A level of the software testing process where a complete, integrated system
is tested. The purpose of this test is to evaluate the system’s compliance
with the specified requirements.
Acceptance Testing
A level of the software testing process where a system is tested for
acceptability. The purpose of this test is to evaluate the system’s
compliance with the business requirements and assess whether it is
acceptable for delivery.

Testing techniques used:

Black Box Testing

A software testing method in which the internal structure/design/implementation of
the item being tested is not known to the tester. These tests can be functional or
non-functional, though usually functional. Test design techniques
include Equivalence partitioning, Boundary Value Analysis, Cause-Effect Graphing.
White Box Testing
A software testing method in which the internal structure/design/implementation of
the item being tested is known to the tester. Test design techniques include Control
flow testing, Data flow testing, Branch testing, Path testing.
Gray Box Testing
A software testing method which is a combination of Black Box Testing method and
White Box Testing method.
.

2.4.6 Post Implementation Maintenance

The product is installed and used for the purpose for which it was constructed. Any
useful product, however, is almost certain to undergo postdelivery maintenance,
either to find x faults (corrective maintenance) or extend the functionality of the
product (enhancement). Because a product consists of more than just the source
code, any changes to the documentation, manuals, or any other component of the
product after it has been delivered to the client are examples of postdelivery
maintenance.
There are three main reasons for making changes to a product:
1. A fault needs correcting, whether an analysis fault, design fault, coding fault,
documentation fault, or any other type of fault. This is termed corrective
maintenance.
2. In perfective maintenance, a change is made to the code to improve the
effectiveness of the product. For instance, the client may wish additional
functionality or request that the product be modifi ed so that it runs faster.
Improving the maintainability of a product is another example of perfective
maintenance.
3. In adaptive maintenance, a change is made to the product to react to a change
in the environment in which the product operates. For example, a product almost
certainly has to be modifi ed if it is ported to a new compiler, operating system, or
hardware.
Regression Testing is done when you have made changes in the system to
ensure the old functionality still remains. This test is very important, but
rather tiring and time consuming.

2.5 Design and Implementation Constraints

2.5.1 User Interface Constraints

Using this portal is fairly simple and intuitive. A user familiar with basic browser
navigation skills should be able to understand all functionality provided by the
portal.

2.5.2 Hardware Constraints

The portal should work on most home desktop and laptop computers.

2.5.2 Software Constraints

The portal is designed to run on Google Chrome, Mozilla Firefox and Internet
Explorer 10.

2.5.3 Data Management Constraints

Portal shall be able to interface with other components according to their

specifications.
2.5.4 Design Standards Compliance

The portal shall be implemented in ASP.NET

2.5.5 General Constraints

 The information of all the users must be stored in a database that is
accessible by the Student Feedback System.
 The university information security system must be compatible with the
Internet applications.
 The users must have their correct usernames and passwords to enter into
the

2.5.6 Assumptions
 The users should have knowledge of basic technical words.
 Users must know the navigations and tabs of the page

2.5.7 Dependencies
 The users should have sufficient knowledge of computers.
 The college computer should have Internet connection and Internet server
capabilities.
 The users know the English language, as the user interface will be provided
in English.

2.5.8 User Characteristics:

The users of the system are students, teachers and the administrators who
maintain the system.
 The users are assumed to have basic knowledge of the computers and
Internet browsing.
 The administrators of the system to have more knowledge of the internals of
the system and is able to rectify the small problems that may arise due to disk
crashes, power failures and other catastrophes to maintain the system.
 The proper user interface, users manual, online help and the guide to install
and maintain the system must be sufficient to educate the users on how to
use the system without any problems.

CHAPTER 3: FUNCTIONALITY

3.1 Logical Database Design

3.1.1 ERD
An entity relationship diagram (ERD) shows the relationships of entity sets stored
in a database. An entity in this context is an object, a component of data. An entity
set is a collection of similar entities. These entities can have attributes that define
its properties.
In ‘Student Feedback System’ we have three basic entities and two extended
entities of staff. Their respective attributes shows single-valued property of either
an entity-type or a relationship-type.
For admin entity there are two attributes userId and password.
For student entity there are following attributes:
 User id
 Name
 Course
 Date of birth
 Email
 Password
 Mobile Number
For Staff entity there are two extended entities named HOD and faculty. Staff
entity has following attributes:
 User Id
 Name
 Department
 Email
 Password
 Mobile number
For HOD entity there are two attributes HOD and subject.
For Faculty entity there is only one attribute subject.

The relationship between entities are shown using Diamond boxes.

3.1.2 Table Structures
3.2 INPUT DESIGN
3.2.1 Login Panel
3.2.1.1 Layout : Login
3.2.1.2 Purpose : On this page user have to login for further process with
valid Id and password.
3.2.1.3 Description of each field
 Time : Shows the current time.
 Title1 : shows the Student Feedback system as the title
 Title 2 : shows the Login as the title
 Link1 ,Link2, Link3 : shows the hyperlinks to various other
pages
3.2.1.4 Validation Check
The password should be alphanumeric i.e. It must contain an Uppercase
letter, a lowercase letter and a number.

Title1
Time

Title2

Link 1

Image

Link 2 Login Panel

Link 3

Background: Red with black Audio: NO

Colour Scheme: Maroon(crayola) Video: No

Text Attributes: Times New Roman Stills: Images

3.2.2 Admin Home page

3.2.2.1 Layout : Admin Home
3.2.2.2 Purpose : On this page admin can add/edit/update/delete/display
feedback
3.2.2.3 Description of each field
 Time : Shows the current time.
 Title : shows welcome admin as the title
 Image: Shows an image
 Form detail : shows the tabs and buttons to perform
functions for student feedback system.
 Link1 ,Link2, Link3 : shows the hyperlinks to various other
pages
3.2.2.4 Validation Check
No validation

Menu Bar
Time
Title

Link1

Image Form Detail

Link2

Link3

Background: Red with black Audio: NO

Colour Scheme: Maroon(crayola) Video: No

Text Attributes: Times New Roman Stills: Images

3.2.3 Student Home page

3.2.3.1 Layout : Student Home
3.2.3.2 Purpose : On this page students can register and give their feedbacks by
entering the required details
3.2.3.3 Description of each field
 Time : Shows the current time.
 Title : shows Student Registration form as the title
 Image: Shows an image
 Form detail : shows the textboxes, labels and buttons to
register for student feedback system.
 Link1 ,Link2, Link3 : shows the hyperlinks to various other
pages
3.2.2.4 Validation Check
No validation

Menu Bar
Time
Title

Link1

Image Form Detail

Link2

Link3

Background: Red with black Audio: NO

Colour Scheme: Maroon(crayola) Video: No

Text Attributes: Times New Roman Stills: Images

3.2.4 Faculty Home page

3.2.4.1 Layout : Faculty Home
3.2.4.2 Purpose : On this page faculty can register and view feedback
3.2.4.3 Description of each field
 Time : Shows the current time.
 Title : shows Faculty Registration form as the title
 Image: Shows an image
 Form detail : shows the textboxes, labels and buttons to
register for student feedback system.
 Link1 ,Link2, Link3 : shows the hyperlinks to various other
pages
3.2.4.4 Validation Check
No validation

Menu Bar
Time
Title

Link1

Image Form Detail

Link2

Link3

Background: Red with black Audio: NO

Colour Scheme: Maroon(crayola) Video: No

Text Attributes: Times New Roman Stills: Images

3.2.5 Contact Us
3.2.5.1 Layout : Contact Us
3.2.5.2 Purpose : On this page User can contact the operator for queries and
doubts.
3.2.5.3 Description of each field
 Time : Shows the current time.
 Title : shows Contact Us as the title
 Image: Shows an image
 Menu Bar :contains the tabs and lists to perform functions.
 Text Information : Contains the Contact number along with
the operator name in the form of text.
 Link1 ,Link2, Link3 : shows the hyperlinks to various other
pages
3.2.5.4 Validation Check
No validation

Menu Bar
Time
Title

Link1

Image

Link2
Text Information

Link3

Background: Red with black Audio: NO

Colour Scheme: Maroon(crayola) Video: No

Text Attributes: Times New Roman Stills: Images

3.3 USE CASE DESCRIPTION
Use Case: Login

Summary: Login will help user and admin to login information by entering
valid Id and password.

Actors: Registered Student, Faculty, HOD

Precondition: only registered user can login

Description:This scenario describes the situation where login is required.

This is the main success scenario.
1. Student will open the system to login.
2. Student has to enter a valid user Id.
3. Student has to enter valid password to login.
4. Student will enter the submit button.
5. OTP will be send to confirm the student to corresponding registered email
address.
6. Student will enter the OTP.
7. Admin will verify the student information.
8. Now, Student can access the student feedback system.

Exception:
1. Wrong password and User Id.
2. Email address not valid.
3. Problem in generating OTP.

Post condition: Welcome screen will be pop out after 3 second.

Use case: Update Questions

Summary: This help admin to update the feedback form.

Actors: Admin

Precondition: Questions shouldn’t be present in the form already.

Description: This scenario describes the situation where questions will be

added to feedback form to improve the feedbacks. Following flow of
activities are performed:
1. Admin will open the feedback form.
2. Admin Will Click on Update questions button.
3. Admin has to choose the department of which he want to update
questionnaires.
4. Admin will add or delete questions.
5. Updates the questionnaires.
6. Click on confirm button.
7. The questionnaires will be updated.

Exception: Question is already added to the form.

Post condition: System may take some time in updating the

Questionnaires.

Use case: Update Records

Summary: This help admin to update record of feedbacks received.

Actors: Admin

Precondition: Feedback should be submitted by the user.

Description: This use case updates the record of the feedback submitted
by the user . This module is used every time a student submits feedback.
Following flow of activities are performed:

1. Admin will open the feedback form.

2. Admin Will Click on Update Records.
3. Admin has to choose the department of which he want to update
Record.
4. If Admin wants to add to the record then:
 Admin will add the questionnaire result.
 Admin will add the grades given by student.
 Admin will add the comment and suggestions to be reflected on the
screen.
 Press on ADD button.
5. If Admin wants to delete something from record then:
 Admin will choose the option from comment and questionnaire result
which he wants to be deleted.
 Admin will choose the data he wants to delete.
 Press on DELETE button.
6. Admin will Click on UPDATE button.
7. The Records will be updated and reflected on the reports module.

Exception: Student has not completed the feedback process and

information is less to be reflected in report module.

Post condition: System may take some time in updating the Records.

Use case: View Questions

Summary: This help the faculty and HOD to view Questionnaires.

Actors: Faculty, HOD, Admin

Precondition: Questionnaires must be added

Description: To View the questionnaires:

1. Faculty and HOD must login to the system.

 After login they have to click on student feedback form.
 Click on questionnaires button
 Select the type of Questionnaires like Development, Academic etc.
 The questionnaire view can be seen.
2. Admin can view questionnaires by logging in.
 Admin have to select department.
 Select type of questionnaires.
 The questionnaires can be seen.
Exception: Questionnaires are not relevant.

Post condition: Viewing questionnaires may take time.

Use case: Student Feedback Form

Summary: This help student to give feedback and give suggestions.

Actors: Student.

Precondition: For giving the feedback.

Description: Student will enter the system.

 There will be 3 blocks:

1. Feedback
2. Grades
3. Comments
 The students have to enter feedback block first
 In feedback block he will answer the questionnaires.
 Then, he will enter the grades module.
 In Grades block, he will give the grade from A to D
 Then students can give suggestions and comments in Comments
section.

Exception: feedback is not completed.

Post condition: Feedback submission takes time.

Use case: View Report.

Summary: This help new user to view report

Actors:Admin,HOD

Precondition:The report must be generated

Description:

1.The system will first check if the user is admin or HOD because report
can be seen by them only.

2. Then System will check if the report is generated.

3.If the report is generated the report can be viewed on 2 basis:

 Departmental Report
 Overall Report
Exception:Report doesn’t contain whole information

Post condition: Report view is taking time to fetch data.

Use case: Logout.

Summary: This help new user to logout.

Actors: Student, HOD, faculty.

Precondition: User must login.

Description: This use case is used when the user wants to log out from the
system.

 User will click on profile.

 Then he will go to log out block.
 The user will be logged out from the system.

Exception: NA

Post condition: Log out will take some time.