Project Title: Submitted by

DEPARTMENT OF COMPUTER SCIENCE,
INSTITUTE OF SOUTHERN PUNJAB, MULTAN
Project Title
AN AUTOMATED CLASSROOM
ATTENDENCE SYSTEM USING
FACE RECOGNITION
Submitted By
Mr. AMMAD UL ISLAM
BSCS-023A16-21
Submitted To
Mr. MUNEEB AHMED KHAN
Date of Submission
21ST APRIL, 2020
Student Signature Supervisor Signature Director FYP
DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

Date: Date:
Date:
Table of Contents
Revision History....................................................................Error: Reference source not found
1. Introduction..............................................................................................................................3
1.1 Purpose.......................................................................................................................................3
1.2 Document Conventions..............................................................................................................3
1.3 Intended Audience and Reading Suggestions.............................................................................3
1.4 Product Scope.............................................................................................................................3
1.5 References………………………………………………………………………………. 4
2. Overall Description………………………………………………………………………………………………………….4
2.1 Product Perspective…………………………………………......................................................4
2.2 Product Functions……………………………………………....................................................4
2.3 User Classes and Characteristics……………………………………………….4
2.4 Operating Environment………………………………………………………………………5
2.4.1 Software Specifications……………………………………………………5
2.4.2 Hardware Specifications………………………………………………………………………………5
2.5 User Documentation……………………………………………………………………………….5
3. External Interface Requirements...........................................................................................6
3.1 User Interfaces............................................................................................................................6
3.1.2 Hardware Interfaces....................................................................................................................6
3.1.3 Software Interfaces.....................................................................................................................6
3.1.4 Communications Interfaces……………..………………………………………………………6
4. Domain Model..........................................................................................................................6
5. Functional Requirements........................................................................................................6
5.1 Use Case Overview....................................................................................................................7
5.2 Student Use Case........................................................................................................................8
5.3 Register Use Case.......................................................................................................................9
5.4 Image Acquisition Use Case.....................................................................................................10
5.5 System Login Use Case............................................................................................................11
5.6 Get Result Use Case.................................................................................................................11
5.7 Update Student Use Case..........................................................................................................12
5.8 Set Configurations Use Case....................................................................................................12
6. Nonfunctional Requirements................................................................................................12
6.1 Reliability.................................................................................................................................13
6.2 Ease of Use...............................................................................................................................13
6.3 Feasibility Study.......................................................................................................................13
6.3.1. Technical Feasibility………………………………………………………………………………………………… 13
6.3.2. Operational Feasibility…………………………………………………………………………………………….. 13
6.3.3. Economic Feasibility……………………………………………………………………………………………….. 13
6.3.4. Schedule Feasibility………………………………………………………………………………………………… 13
7. Other Requirements..............................................................................................................14

Appendix A: Glossary...........................................................................................14
Appendix B: Analysis Models.....................................................................................................14
Appendix C: To Be Determined List………………………………………………………......14
1. INTRODUCTION
1.1 Purpose
AIM OF THIS PROJECT IS TO CREATE DOCTOR PATIENT HANDLING MANAGEMENT SYSTEM THAT
WILL HELP DOCTORS IN THEIR WORK AND WILL ALSO HELP PATIENTS TO BOOK DOCTOR
APPOINTMENTS AND VIEW MEDICAL PROGRESS. THE SYSTEM ALLOWS DOCTORS TO MANAGE
THEIR BOOKING SLOTS ONLINE. PATIENTS ARE ALLOWED TO BOOK EMPTY SLOTS ONLINE AND
THOSE SLOTS ARE RESERVED IN THEIR NAME. THE SYSTEM MANAGES THE APPOINTMENT
DATA FOR MULTIPLE DOCTORS OF VARIOUS DATE AND TIMES. EACH TIME A USER VISITS A
DOCTOR HIS/HER MEDICAL ENTRY IS STORED IN THE DATABASE BY DOCTOR.
Document Conventions
Documentation conventions deal with the font size, headings and other alignments criteria that
we have used to design this document are Font will be Time New Roman and Size will be 12.
First heading bold and 14. Second heading bold and 13. Third heading bold and 12. Line spacing
is 1.5.
1.2 Intended Audience and Reading Suggestions
This project is aimed to develop the web base application to consult the doctor. Objective is to
provide cheap and easier consultation system for the patients.
Many doctors don’t have clinics so this is golden opportunity for them to earn online by sitting in
their offices or homes. Conversation of the doctor and patient is encrypted and secured. Special
Security and privacy for female’s patients

1.3 Product Scope
This online portal is allowed you to book appointment online for easier and cheaper consultation.
We have doctors, patients, lab and store.
You can pay online before consultation and after that when the consultation time will meet you
can solve your issue with our qualified doctors.
1.4 Reference
https://oladoc.com/
https://www.freeprojectz.com/paid-projects/php-mysql/doctor-appointment-system

2. OVERALL DISCRIPTION
2.1 Product Perspective
A class room attendance system that will snap a class room picture and segment all faces
from that image and match OR recognize from database and show it as present \absent record
into the crystal record. Furthermore this system will have a crystal report for attendance of
students.
2.2 Product Functions
 User account creation

 Delete user account
 Maintain records of students
 User Log in
 User Log out
 Allow administrator to update attendance
2.3 User Classes and Characteristics
Users of the system are faculty members, students and administrators.

 Faculty members: They can use all the functionality provided within a system. Registered
users have their own profile.
 Administrator: The system administrator has more information about the internal of the
system and can fix minor issues that may arise. Maintain the right to update / delete
registered users.

There are the two user classes: Faculty members and Administrator.
The following table represents the functionality guidelines of these user classes.
Faculty
Function Member Administrator
Register YES YES
Login YES YES
Add Student YES
Delete Student YES
Update Attendance YES YES
2.4 Operating Environment
2.4.1 SOFTWARE SPECIFICATONS
1. PYTHON (Sublime, Spyder)

2. OPEN CV LIBRARY OF IMAGE PROCESSING
3. NUMPY (For Mathematical Operation)
4. HAAR CASCADE (object detection algorithm)
2.4.2 HARDWARE SPECIFICATONS

● Windows 8/10
● Ram: 8GB
● Hard disk: 500GB
● CPU: 2.5GHZ
● IP Camera with 1 MEGA PIXEL
● USB Port: 1xUSB 2.0 or Better Port
2.5 User Documentation

At the completion of development, a user manual and implementation guide will be made
available to the Customer.

3. Requirements Specification
3.1 External Interface Requirements
3.1.1. User Interfaces
The user interface will run on Windows.
3.1.2. Hardware Interfaces
The Face Detection and Recognition system require a camera. The camera requires
necessary driver installed within the operating system. Also, it requires 1 USB port on
the PC.
3.1.3. Software Interfaces
There are no external software interface requirements.
3.1.4. Communication Interfaces
There are no external communications interface requirements
4. Domain Model
N/A
5. Functional Requirements:
The functional requirements for a system describe what the system should do. Those
requirements depend on the type of software being developed, the expected users of the
software. These are statement of services the system should provide, how the system
should react to particular inputs and how the system should behave in particular situation.
Some functional requirement describes activities and services that must provide.
 A user must be able to manage student records.

 An only authorized user must be able to use the system.
 The administrator or the person who will be given the access to the system must login
the system before using it.
 The information must be entered and managed properly.

 System must capture faces.
• System must store faces in a DB attached to the Student’s ID.
• System must recognize the student to enable attendance marking.
5.1 Use Case Diagram

Use Case Diagram (UCD) for this project is shown in Figure 2. After some analysis
of the system development process, The Use Case Diagram is created. This User Case
Diagram can be modified during later parts of the project.

5.2 Student Use Case
Specification of actors
In the analysis stage of the Face Recognition Attendance System development process,
actors below are described so far.

5.3 Register Use Case
Specification of Use Cases

5.4 Image Acquisition Use Case

5.5 System Login Use Case
5.6 Get Result Use Case

5.7 Update Student Use Case
5.8 Set Configurations Use Case
6. Non-Functional requirements:
Nonfunctional requirements are requirements that are not directly concerned with the
specified function delivered by the system. They may relate to emergent system
properties such as reliability, response time and store occupancy. Some of the
non-functional requirements related with this system are hereby below:

6.1 Reliability:
Reliability based on this system defines the evaluation result of the system, correct
identification of the facial expressions and maximum evaluation rate of the facial
expression recognition of any input images.
6.2 Ease of Use:

The system is simple, user friendly, graphics user interface implemented so any can use
this system without any difficulties.
6.3. Feasibility Study

Before starting the project, feasibility study is carried out to measure the viable of the
system. Feasibility study is necessary to determine if creating a new or improved system
is friendly with the cost, benefits, operation, technology and time. Following feasibility
study is given as below;
6.3.1. Technical Feasibility

Technical feasibility is one of the first studies that must be conducted after the project has
been identified. Technical feasibility study includes the hardware and software devices.
The required technologies (PYTHON language, openCV) existed.
6.3.2. Operational Feasibility

Operational Feasibility is a measure of how well a proposed system solves the problem
and takes advantage of the opportunities identified during scope definition. The following
points were considered for the project’s technical feasibility:
The system will detect and capture the image of face.
The captured image is then (identified which category)
6.3.3. Economic Feasibility

The purpose of economic feasibility is to determine the positive economic benefits that
include quantification and identification. The system is economically feasible due to
availability of all requirements
6.3.4. Schedule Feasibility

Schedule feasibility is a measure of how reasonable the project timetable is. The system
is found schedule feasible because the system is designed in such a way that it will finish
prescribed time.

7. Other Requirements
N/A
Appendix A: Glossary
N/A
Appendix B: Analysis Models

N/A
Appendix C: To Be Determined List

N/A

Project Title: Submitted by

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Title: Submitted by

Uploaded by

Copyright:

Available Formats

DEPARTMENT OF COMPUTER SCIENCE,

INSTITUTE OF SOUTHERN PUNJAB, MULTAN

Student Signature Supervisor Signature Director FYP

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

APPOINTMENTS AND VIEW MEDICAL PROGRESS. THE SYSTEM ALLOWS DOCTORS TO MANAGE

DOCTOR HIS/HER MEDICAL ENTRY IS STORED IN THE DATABASE BY DOCTOR.

1.2 Intended Audience and Reading Suggestions

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

1.3 Product Scope

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

2.1 Product Perspective

2.2 Product Functions

 User account creation

2.3 User Classes and Characteristics

Users of the system are faculty members, students and administrators.

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

2.4 Operating Environment

2.4.1 SOFTWARE SPECIFICATONS

1. PYTHON (Sublime, Spyder)

2.4.2 HARDWARE SPECIFICATONS

2.5 User Documentation

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

3.1 External Interface Requirements

3.1.1. User Interfaces

The user interface will run on Windows.

3.1.2. Hardware Interfaces

3.1.3. Software Interfaces

There are no external software interface requirements.

3.1.4. Communication Interfaces

There are no external communications interface requirements

 A user must be able to manage student records.

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

 The information must be entered and managed properly.

• System must store faces in a DB attached to the Student’s ID.

• System must recognize the student to enable attendance marking.

5.1 Use Case Diagram

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

5.2 Student Use Case

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

5.3 Register Use Case

Specification of Use Cases

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

5.4 Image Acquisition Use Case

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

5.5 System Login Use Case

5.6 Get Result Use Case

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

5.7 Update Student Use Case

5.8 Set Configurations Use Case

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

6.2 Ease of Use:

6.3. Feasibility Study

6.3.1. Technical Feasibility

6.3.2. Operational Feasibility

6.3.3. Economic Feasibility

6.3.4. Schedule Feasibility

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

Appendix B: Analysis Models

Appendix C: To Be Determined List

DEPARTMENT OF COMPUTER SCIENCE, INSTITUTE OF SOUTHERN PUNJAB, MULTAN

You might also like