sacsdeveloperceng.weebly.com/uploads/2/5/5/8/25580030/srs-2.0.pdfsacs srs 2.0 1 sacs software...
TRANSCRIPT
SACS SRS 2.0
1
SACS
Software Requirement Specification
CENG490
DEVELOPERCENG
Abdulaziz AYDOĞMUŞ
Akın YILMAZ
Emre Deniz ÖZER
İlker YILDIRIM
SACS SRS 2.0
2
Change History
Date Revision Comment
27.11.2013 1.0 Created
27.12.2013 2.0 Correction revisions
28.12.2013 2.0 Table of Figures is added
SACS SRS 2.0
3
Table of Contents
1. Introduction ........................................................................................... 6
1.1 Problem Definition ............................................................................................................ 6
1.2 Purpose ............................................................................................................................ 6
1.3 Scope ............................................................................................................................... 6
1.4 Definitions, acronyms, and abbreviations .......................................................................... 7
1.5 References ....................................................................................................................... 7
1.6 Overview .......................................................................................................................... 7
2. Overall description ............................................................................... 8
2.1 Product perspective .......................................................................................................... 8
2.1.1 System Interfaces ...................................................................................................... 9
2.1.2 User interfaces ..........................................................................................................10
2.1.3 Hardware interfaces ..................................................................................................11
2.1.4 Software interfaces ...................................................................................................11
2.1.5 Communication interfaces .........................................................................................11
2.1.6 Memory .....................................................................................................................12
2.1.7 Operations ................................................................................................................12
2.1.8 Site adaptation requirements ....................................................................................12
2.2 Product functions .............................................................................................................13
2.2.1 Server functions of the product ..................................................................................13
2.2.2 External and Client Based Functions of System ........................................................14
2.3 Constraints ......................................................................................................................19
2.4 Assumptions and dependencies ......................................................................................19
3. Specific requirements ........................................................................ 20
3.1 Interface Requirements ...................................................................................................20
3.2 Functional Requirements Specification ............................................................................20
3.2.1 User Use Cases ........................................................................................................20
3.2.2 Operator use cases ...................................................................................................29
3.2.3 Internal Function’s Requirements ..............................................................................32
3.3 Non-functional Requirements ..........................................................................................34
SACS SRS 2.0
4
3.3.1 Performance requirements ........................................................................................34
3.3.2 Design constraints .....................................................................................................34
4. Data Model and Description ............................................................... 34
4.1 Data Description ..............................................................................................................34
4.1.1 Data objects ..............................................................................................................35
4.1.2 Data dictionary ..........................................................................................................36
5. Behavioral Model and Description ................................................... 37
5.1 Description for software behavior ....................................................................................37
5.2 State Transition Diagrams ...............................................................................................37
6. Planning .............................................................................................. 38
6.1 Team Structure ................................................................................................................38
6.2 Estimation (Basic Schedule) ............................................................................................38
6.3 Process Model .................................................................................................................38
7. Conclusion .......................................................................................... 38
SACS SRS 2.0
5
Table Of Figures
Figure 1: An Example Product ................................................................................................... 8
Figure 2: Block Diagram of general system ................................................................................ 9
Figure 3: Login Function ...........................................................................................................14
Figure 4: Search Function .........................................................................................................14
Figure 5: Camera Control Function ...........................................................................................15
Figure 6: Student Matching Function .........................................................................................15
Figure 7: Error Report Function .................................................................................................16
Figure 8: Attendance Report Function .......................................................................................16
Figure 9: Schedule Creation Function .......................................................................................16
Figure 10: Editing Class Info .....................................................................................................17
Figure 11: Checking Face Recognition Quality..........................................................................17
Figure 12: Checking Face Detection Quality .............................................................................18
Figure 13: Allowing/Disallowing System to Create Database ....................................................18
Figure 14: User Use Cases .......................................................................................................20
Figure 15: Use case: Log in ......................................................................................................21
Figure 16: Use case: Search .....................................................................................................22
Figure 17: Use case: Camera Control .......................................................................................23
Figure 18: Use case: Student Matching ....................................................................................24
Figure 19: Use case: Error Report.............................................................................................25
Figure 20: Use case: Attendance Report ...................................................................................26
Figure 21: Use case: Schedule Creation ...................................................................................27
Figure 22: Use case: Editing Class Info ....................................................................................28
Figure 23: Operator use cases ..................................................................................................29
Figure 24: Use Case : Checking Face Recognition Quality .......................................................29
Figure 25: Use Case : Checking Face Detection Quality ...........................................................30
Figure 26: Use Case : Allowing/Disallowing System to Create Database ..................................31
Figure 27: Data dictionary .........................................................................................................36
Figure 28: State Transition Diagrams ........................................................................................37
SACS SRS 2.0
6
1. Introduction
1.1 Problem Definition
Many teachers, especially the ones who teach at universities, spend a lot of time while
taking the attendance of the class. If the lecture is given in an auditorium, then this operation
turns into a trouble for the lecturers. When they give grades to the students according to their
participation to the lectures, they have to read all the attendance lists that are taken during the
semester and they have to make some grading calculations to define the actual attendance
grades of the students. The lecturers suffer from this situation a lot and it is very time-
consuming. Furthermore, the students who are present at the class can sign the attendance
sheet on behalf of the absent students and this is an illegal action for the students. For lecturers
to follow this illegal action is again very hard and generally, they continue to the lectures without
attendance check.
1.2 Purpose
The purpose of this report is mainly explain in details the requirements of our project.
This document is intended to be used by the members of the project team that will implement
and verify the correct functioning of the system. It will explain the purpose and features of the
system, the interfaces of the system, what the system will do, the constraints that it must
operate. The parts for developers will be included in our report like data flows and which
languages and can be used. In addition, users can use product functions and use case
diagrams to learn how the product can be used.
1.3 Scope
The “Student Attendance Checker System” (SACS) is a software application which make
automatic the checking attendance in the classrooms. There will be cameras in the classroom
and the attendance will be taken with these cameras. Instructors will be able to determine the
lecture hours and the lecture class information to the system. The detected students by the
system will be compared with the students registered for that course. The users for our system
is only the instructors and the students cannot use the system. Client side will get the
information via internet. Software needs a server computer, enough cameras as a hardware
components. In addition, there must be internet connection to connect to the server side from
client side. If it faces with some problems, the technician will be able to fix it.
SACS SRS 2.0
7
1.4 Definitions, acronyms, and abbreviations
SACS: Students Attendance Checker System
DBMS: Database Management System
SRS: Software Requirements Specification
OPENCV: Open Source Computer Vision
HTML: Hyper Text Markup Language
CSS: Cascading Style Sheets
SQL: Structured Query Language
MYSQL: The world's second most widely used open-source relational database
management system
1.5 References
1. Book: Handbook of Face Recognition, Stan Z. Li Anil K. Jain, Springer- Verlag London
Limited 2011
2. Example SRS reports from CENG 491 web page.
3. StarUML 5.0 User Guide. (2005). Retrieved from http://staruml.sourceforge.net/docs/user-
guide(en)/toc.html
1.6 Overview
The next chapter, the Overall Description section, of this document gives an overview of
the functionality of the product. It describes the informal requirements and is used to establish a
context for the technical requirements specification in the next chapter.
The third chapter, Specific Requirements section, of this document is written primarily for
the developers and describes in technical terms the details of the functionality of the product.
Both sections of the document describe the same software product in its entirety, but are
intended for different audiences and thus use different language.
SACS SRS 2.0
8
2. Overall description The software product will concentrate on facial detection and recognition of the students
to help lecturers to take the attendance of the class. Basically, this software product will be a
web application at the client side in which instantaneous video of the class will be seen on the
screen after a successful access to the system. At the server side, face detection and
recognition operations will be handled and the results will come out according to these
operations. Furthermore, database operations will also be handled at the server side.
2.1 Product perspective
SACS (1.4) is a system that has parts in server and client part. The server performs
internal functions of the system like face detection and face recognition modules. With this
information coming from the server, clients can take attendance information of students. The
client program is a web based application that takes results from the server.
There are many applications and systems in the market about attendance checking.
They are mostly used in offices to check time attendance of employees. These technologies are
usually embedded devices that have a camera and sensor, processing units, storage units and
external interfaces.
However our product approaches attendance taking mechanism in a different way. In
other devices users usually should do something to make themselves to be identified by the
system, for example closing up their faces to device etc. Our system will perform the process
effortlessly and dynamically. An example of devices that are used commonly is shown in the
image below (Figure 1) :
Figure 1: An Example Product
SACS SRS 2.0
9
Our system is not an embedded system. It works on Windows and Linux operating system and
also in desktop operating systems that can run our executable via helper programs. The
camera is a separate device that is connected to server computer. Server and client programs
are run in a computer that has an operating system. The general block diagram for the system
can be seen below image (Figure 2):
Figure 2: Block Diagram of general system
2.1.1 System Interfaces
There are several systems connected in our product. Firstly there is a camera system
and server system connected. Camera system and server system connected via 'Camera
Driver' that is installed in the server computer. With this interface camera can send image and
video information to the server computer and server computer can send commands to camera
to turn off or turn on etc. A client can send directives to camera via server computer to camera
with this interface. Also server computer takes info to perform related operations about
'Attendance Checking' process. Secondly client computer systems is connected to server
systems with web requests, means client can reach the shared data of server computer via
internet. So there is a web interface to communicate these two systems. We will use internet
protocol to connect these two systems. Also MYSQL database via scripting language will be
used for communication .Several systems connected in our product. Firstly there is a camera
system and server system connected. Camera system and server system connected via
SACS SRS 2.0
10
'Camera Driver' that is installed in the server computer. With this interface camera can send
image and video information to the server computer and server computer can send commands
to camera to turn off or turn on etc. A client can send directives to camera via server computer
to camera with this interface. Also server computer takes info to perform related operations
about 'Attendance Checking' process. Secondly client computer systems is connected to server
systems with web requests, means client can reach the shared data of server computer via
internet. So there is a web interface to communicate these two systems. We will use internet
protocol to connect these two systems. Also MYSQL database via scripting language will be
used for communication.
2.1.2 User interfaces
Our product is a web application. In our user interface, user will face to Login Screen.
After successful login operation There is another page that represents some choices according
to the user authority. These are:
● Arrange lessons (time, place etc.)
○ In this area user can arrange lessons at a specific time range and its frequency
and its place.
● Define students to the system
○ In this area user can make definition of students and upload their photos to
system.
● Enter and change student enrollment list of a course to the system
○ In this area user can enter all students of the course to the system’s course
enrollment list.
● Display student attendance reports
○ In this area user can display attendance reports with some options like at a time
range, for whole class, for a single student etc.
● Send feedback to the system about an attendance information.
○ In this area if there is a mistake in the face detection system that causes
incomplete attendance and correct the mistake.
● Arrange Camera settings
○ In this area user can make settings for cameras in classes.
Also the operator will have an interface in the server side for checking :
SACS SRS 2.0
11
- Face detection quality
- Face recognition quality
- Managing storing options of systems
2.1.3 Hardware interfaces
We will have camera and server hardware components for our application. There will be
a communication between camera and the server with USB port and some cables. With these
cables camera and server computer will be connected by using camera driver in the server
computer. Our server computer will have enough capabilities and properties. You can see
2.1.6(Memory) part for specific information.
2.1.4 Software interfaces
Server Side
The software will be hosted on user’s computer and will be connected to the server on
the department. The server is listening on the web standard port, port 80. In order to access the
data that are produced by the system, the server must have MYSQL database system.
Furthermore, OPENCV 2.4.6 must be used in order to perform necessary operations in the
system.
Client Side
The system is a web application. In order to run the system properly, the user must use
a modern web browser such as Mozilla Firefox 24.0, Google Chrome. The computer must have
an Internet connection in order to be able to access the system. Any operating system can be
used on the client side.
2.1.5 Communication interfaces
The HTTP protocol will be used to connect server computer and client computer. Server
will reply HTTP calls of client computers to send necessary information. Also there will be a
USB data sending protocol for connection between camera and server computer.
SACS SRS 2.0
12
2.1.6 Memory
Enough main memory requirements are the requirements for running our program
seamlessly. There should be enough main memory to process related information, latest
modern computers with average RAM is sufficient with small amount of data (i.e. Classes with
20 students). On our trials we have seen especially image processing algorithms and
recognition algorithms use intensive memory from system. With an average RAM computer (4
GB RAM) we have seen there is some memory allocation problems after the number of 20
students. This make longer the processing time. Otherwise server computers should be
stronger in terms of main memory. Enough space for storing database and image information
should be provided in the hard disk of server computer. This space information is estimated
from the size of images that are in the server. The system saves databases and image files to
hard disk of the server computer. For a system of 20 students, the optimal database size is 40
MB. The size of the database must be bigger for bigger number of students. Images of students
are stored in the hard disk. Each image of student is approximately 50 KB and there are 100
images of each student with their temporary images. Because of this for a healthy system with
20 students, there must be at least 200 MB of data storage in the hard disk of server computer.
The additional storage is used for storing raw images from the camera.
In the client side, it is OK to use average computers that run a web browser. (Average
computers sold in market)
2.1.7 Operations
User organizes the time and the place of lessons to take attendance from class. There is
no periodic interactive operations but there is a period constraint for some unattended
operations like getting view of class at least one time during lecture .
2.1.8 Site adaptation requirements
If OPENCV acceleration is wanted, higher Ram (at least 6 GB) and latest graphic cards
(NVIDIA GeForce GT 720M) can be used.
SACS SRS 2.0
13
2.2 Product functions
2.2.1 Server functions of the product
These functions are used and run in the server of product.
2.2.1.1 Face Detection Module
This function of the system is run in the server. The job of this module is taking photos
from the connected camera and after processing coming images, the system will try to find
faces from the images. After finding faces, the system will try to send the related images to
server hard disk and database system. These info will be used by the ‘face recognition’ module
of the system. Also face detection module will identify the place of the each face in the
classrooms for making a healthier conclusion about next image coming from the camera.
2.2.1.2 Database and File Management Module
Database module will be used for storing text and image information coming from user
interface and cameras. This will save the database info like student numbers, names, student’s
facial information, student’s attendance information, errors, course information. This module
also will manage the image files of the students in the classrooms. This module is used as a
transition between face detection module and face recognition module. This module is also
used by client for retrieving information of students, attendance and courses.
2.2.1.3 Face Recognition Module
Face recognition module is used for identifying students in the classrooms then process
the related attendance operation. When images from the face detection module is transferred to
database module and they are ready to be used, face recognition module will use these image
and facial information to try to find a match with student images from the database. If a match is
found between image info and database record then this student is checked as present in the
classroom. Also new images of student are recorded to database as current facial information of
student for a healthier face recognition process next time.
2.2.1.4 Error Correction Module
Error correction module is used by the system automatically for correcting any reported
errors. These errors are failed face recognitions, false face recognitions. Errors are reported by
the user of the system.
SACS SRS 2.0
14
2.2.2 External and Client Based Functions of System
These functions are the functions that are used by clients of the system and takes
information from the server of system.
2.2.2.1 Login Function
Login function is used by the user who has authentication to enter the system. Here is
the actor is teacher who has the attendance control over the classroom. When the user logs
he/she can the access of other related information for the system from the client computer.
Figure 3 show the diagram of the function.
Figure 3: Login Function
2.2.2.2 Search Function
Search function is used for searching a specific student or record from the attendance
record database and after search related information will be showed. Here is again the actor is
the teacher that has control over the class. Figure 4 show the diagram of the function.
Figure 4: Search Function
SACS SRS 2.0
15
2.2.2.3 Camera Control Function
Camera Control function gives the control and state of the camera to the user. User can
control the camera states and can check the camera state information from this function. Figure
5 show the diagram of the function.
Figure 5: Camera Control Function
2.2.2.4 Student Matching Function
In this function the user can match the images sent from the server system with the
related current students that take the class. This function is a verification function that verifies
the student and the actual data taken from the cameras. Also the teacher can enter the names
and numbers of students for better reporting. Figure 6 show the diagram of the function.
Figure 6: Student Matching Function
SACS SRS 2.0
16
2.2.2.5 Error Report Function
In this function, in case of a system error such a mismatched student recognition ,i.e.
Student was in the class but system did not recognize him, teacher can report this to the
system to prevent future mismatches. Figure 7 show the diagram of the function.
Figure 7: Error Report Function
2.2.2.6 Attendance Report Function
In this function, teachers can take student attendance reports from the system. In this
report each student attendance information will be stated as statistical info. Figure 8 show the
diagram of the function.
Figure 8: Attendance Report Function
2.2.2.7 Schedule Creation Function
This function is used when the teacher wants to activate the system in a particular time
interval. For example, when a teacher has a course in a specular time then he uses schedule
creation to use the system in this specular time. Figure 9 show the diagram of the function.
Figure 9: Schedule Creation Function
SACS SRS 2.0
17
2.2.2.8 Editing Class Info
This function is used when the user wants to change class info like time and number of
students; also it is used when teacher wants to remove all information about the class and
students. Figure 10 show the diagram of the function.
Figure 10: Editing Class Info
2.2.2.9 Checking Face Recognition Quality
This function is used by the operator of the system to check the quality of the face
recognition process. If there is an error or poor quality in face recognition process (i.e. There is
a problem in the attendance checking process), the operator then try to establish fix
environmental factors like status of camera and lightning conditions to increase the image
quality taken from the camera. If there is a problem in face matching or taking image info then it
may be fixed by using other functions. Figure 11 shows the diagram of the function.
Figure 11: Checking Face Recognition Quality
SACS SRS 2.0
18
2.2.2.10 Checking Face Detection Quality
This function is used by the operator for checking any poor quality conditions that
prevents the face detection process. These conditions are like lightning conditions and camera
angle. After checking face detection process, the operator takes necessary actions to fix poor
conditions and check again the face detection quality. Figure 12 show the diagram of the
function.
Figure 12: Checking Face Detection Quality
2.2.2.11 Allowing/Disallowing System to Create Database
This function is used by the operator when the server is about to running out of sources
to prevent the system from taking hard disk space. With this function the operator able to stop
system from storing database and image info. In the beginning of the usage of the system, if
there is a poor quality environment, after fixing the problems the operator enables to system to
store information on the hard disk of system permanently. Then the system starts to operate.
Figure 13 show the diagram of the function.
Figure 13: Allowing/Disallowing System to Create Database
SACS SRS 2.0
19
2.3 Constraints
The information about the students cannot be used for other purposes and cannot be
distributed.
The number and quality of cameras used for checking attendance system limit the
number of students can be detected in the classroom. In addition, our product efficiency
alter with the server computer capabilities. For example, with higher processor speed,
more processes can be done.
The garbage must be collected as much as possible. And also there must be enough
dataset photos of the students.
We will use Eclipse IDE for C++, interfaces will be implemented in PHP, MySQL server
will be used for database server and SQL will be used for data management. JavaScript,
HTML, CSS, will be used for user interface. İn addition OPENCV library will be used for
image processing.
There will be only instructors to control and use our system. The students cannot be use
or reach the application.
There will be no electricity dangers and other physical dangers for people using the
system. The project does not harm and does not affect anybody in the classroom.
XON and XOFF will be used in data transmission.
If the system components requirements like camera are provided and the environmental
attributes are enough or good, our system can work as desired.
There will be an operator to construct our system.
2.4 Assumptions and dependencies
The correct functioning of the system will partly be dependent on the correctness of the
data stored and managed as part of the face detection and recognition system. Also, the
application will be hosted by the server as one of many applications; the event of the server
failing due to an error with one of these applications might result in service becoming
temporarily unavailable. If primary database fails then backup database come into the service.
SACS SRS 2.0
20
3. Specific requirements In this section and its subsections, we will explain all the software requirements to a level
of detail sufficient to enable designers to design a system to satisfy those requirements, and
testers to test that the system satisfies those requirements.
3.1 Interface Requirements
Basically the system will have two interfaces. One is between the user and the
application. Besides that the user may want to select scenarios from the hard disc and there
may be an interface between the application and the file system.
3.2 Functional Requirements Specification
This section outlines the use cases for user and owner separately.
3.2.1 User Use Cases
The User has the following sets of use cases (Figure 14):
Figure 14: User Use Cases
SACS SRS 2.0
21
3.2.1.1 Use case: Log in
Diagram:
Figure 15: Use case: Log in
Brief Description
The User enters his specific username and password and logs into the system.
Initial Step-By-Step Description
Before this use case can be initiated, the user has already accessed the Login page of the
system in the client side of the system.
1. The user selects the text input box for the username from the page and enters his
authenticated user name to the field.
2. The user selects the text input box for the password from the page and enters his
authenticated password to the field.
3. User clicks to ‘Login’ button after entering related information.
4. If the authentication is confirmed the user is redirected to his main page.
5. If the authentication fails, then the user takes an error message and login page comes again.
SACS SRS 2.0
22
3.2.1.2 Use case: Search
Diagram:
Figure 16: Use case: Search
Brief Description
The user enters search items to search field and get related results.
Initial Step-By-Step Description
Before this use case can be initiated, the user has already accessed the Login page of the
system.
1. The user enters the related search term like student number and student name to the search
input box.
2. The user clicks ‘Search’ button in the interface.
3. If related results of students are found in the database of the system, it will be shown in the
next page
4. If no results are found, then ‘No Result is Found’ warning will be given.
SACS SRS 2.0
23
3.2.1.3 Use case: Camera Control
Diagram:
Figure 17: Use case: Camera Control
Brief Description
The user selects ‘Camera Control’ screen for controlling the camera and checking the state of
the camera.
Initial Step-By-Step Description
Before this use case can be initiated, the user has to login to system.
1. The user clicks to ‘Camera Control’ link in the main page.
2. In the ‘Camera Control’ page there are 2 options with related buttons. One for turning on and
off the camera and the other is showing the current state of the camera.
3. If the user clicks the ‘Turn on/off camera’ button, then the state of the camera will be
changed.
4. If the user clicks to ‘Show State of Camera’ button, user will see the current state of the
camera. If it is on the camera details like frame rate etc. If it is off, it will show the ‘Camera Off’
statement.
SACS SRS 2.0
24
3.2.1.4 Use case: Student Matching
Diagram:
Figure 18: Use case: Student Matching
Brief Description
The user uses this function to match students that are enrolled to class with the student images
that are coming from the system.
Initial Step-By-Step Description
Before this use case, the user should login and the system should run at least some time that is
enough to extract all image data of students in the classroom.
1. The user selects the ‘Match Students’ menu from the interface.
2. A page with the taken images from the camera exist in the screen. There is two probability.
One is all student face images are showed in a image with their position in the classroom. So
the user’s job is eased to match students. Or the personal images are shown separately and the
user tries to match them.
3. After matching the user enters the related student info of the student (name, number) to the
text box near the image.
4. After completing the job, the user clicks ‘Save Student Info’ button and the student info are
saved to database with the matched images.
5. After saving the user can edit the records by clicking ‘Edit Student Match’ and can change the
match records.
SACS SRS 2.0
25
3.2.1.5 Use case: Error Report
Diagram:
Figure 19: Use case: Error Report
Brief Description
The user can submit errors in face recognition operations to the system with this function.
Initial Step-By-Step Description
Before this use case can be initiated, the user should login to system and the system should
have some image data to match.
1. The user clicks to Report Error button in the interface.
2. With newly opened page the user selects the student record that the error occurs from the
menu.
3. After selecting the student, the user selects the date of error happens.
4. The records of that date is coming to page image by image and the user selects the image
that is thought to be mismatched or no matched.
5. Finally, the user clicks to ‘Report Error’ and the error record is sent to system.
SACS SRS 2.0
26
3.2.1.6 Use case: Attendance Report
Diagram:
Figure 20: Use case: Attendance Report
Brief Description
The user takes the statistical attendance report of each student or all of the attendance report.
Initial Step-By-Step Description
Before this use case can be initiated, the user should login to system and there should be some
attendance records generated by the system.
1. The use clicks ‘Take Attendance Report’ from the user interface.
2. In the new page the user can either select a student record from the menu or select a
‘Course’ and click the ‘Take Report’.
3. In the new page the related attendance report taken from the database will be available in the
screen.
SACS SRS 2.0
27
3.2.1.7 Use case: Schedule Creation
Diagram:
Figure 21: Use case: Schedule Creation
Brief Description
The user created schedule that specifies course information.
Initial Step-By-Step Description
Before this use case can be initiated, the user should be logged in.
1.The user clicks to ‘Create Schedule’ button in the interface.
2. There will be a menu and boxes for specifying course hour interval, duration, number of
students.
3. After specifying properties of course defined above, the user clicks ‘Save Schedule Info’
4. The course information is saved to database to run the system in exact times defined.
SACS SRS 2.0
28
3.2.1.8 Use case: Editing Class Info
Diagram:
Figure 22: Use case: Editing Class Info
Brief Description
The user edits the properties of courses, students, images recorded and also the user can
delete the student, course, image information. The related information of the records will be
deleted too.
Initial Step-By-Step Description
Before this use case can be initiated, the user should be logged in.
1. The user clicks the button name ‘Edit Course’ from the interface.
2. If the user wants to edit or delete a student record he chooses the ‘Edit student’ menu and
selects the students. With the related buttons he can edit and delete records. If a student is
deleted then his all images will be deleted with the permission of the user.
3. If the user wants to edit or delete a course record he chooses the ‘Edit course’ menu and
select the course. Then with related buttons he can edit and delete course record. When a
course is deleted the student records enrolled to this course will be deleted with the permission
of user.
SACS SRS 2.0
29
3.2.2 Operator use cases
Figure 23 show all operator use cases in diagram.
Figure 23: Operator use cases
3.2.2.1 Use Case : Checking Face Recognition Quality
Diagram :
Figure 24: Use Case : Checking Face Recognition Quality
Brief Description
The operator enters to interface of server program and runs checking face recognition function
of the system.
Initial Step-By-Step Description
Before this use case function, operator must enter to the server program and should open the
interface of the program. This use case requires the ‘Face Detection Quality’ function with a
successful result. (i.e. The system can detect faces without problems)
1. The operator selects ‘Check Face Recognition‘ button in the interface.
SACS SRS 2.0
30
2. Then the system starts to face recognition by running face recognition module.
3. System returns results of face recognition to the related screen.
4. The operator checks the result of face recognition.
5. If there is a problem or error, he reports this error to system or fixes the environmental issues.
6. If there is no problem the operator can let the system to start permanently.
3.2.2.2 Use Case : Checking Face Detection Quality
Diagram :
Figure 25: Use Case : Checking Face Detection Quality
Brief Description
The operator enters to interface of server program and runs checking face detection function of
the system.
Initial Step-By-Step Description
1. User clicks to ‘Check Face Detection Quality’ in the interface of the server program.
2. Then the system starts the ‘Face Detection Module’ to make a face detection with the images
coming from the camera.
3. The system returns the results of face detection process and the operator checks the results.
4. If there is a problem with the detection (any missing detection), then the operator fixes the
environmental issues and tries again.
SACS SRS 2.0
31
3.2.2.3 Use Case : Allowing/Disallowing System to Create Database
Diagram :
Figure 26: Use Case : Allowing/Disallowing System to Create Database
Brief Description
The operator enters to interface of the server program and runs ‘Allow/Disallow System to
Create Database’
Initial Step-By-Step Description
1. The operator clicks on ‘Allow/Disallow Database Access’ button in the interface.
2. When the ‘Storing is Active’ message is displayed on the screen, system can use the system
store resources of server computer and can continue to regular process of face detection and
face recognition modules.
3. When the ‘Storing is inactive’ message is displayed, system cannot use the system store
resources.
SACS SRS 2.0
32
3.2.3 Internal Function’s Requirements
This section is for the developers of internal modules of system : face detection, face
recognition, error correction modules.
3.2.3.1 Face Detection Module
Brief Description
This function should take the pictures from the camera then after necessary operations returns
detected faces.
Initial Step-By-Step Description
The camera should send image data to server and the server should have enough capabilities
to store image data coming from the camera in order to this module run correctly. Also
necessary face object specification files (here xml files that stores face features) should be
present in the system. (it will be default present in the system, but it is stated in case of deletion
of files.)
1. The system takes image information from the camera in the class.
2. The camera sends the image information of the classroom to server.
3. Server takes the image information and makes necessary image processing procedures like
lighting correcting etc.
4. The program starts to search for faces with the given face specifications.
5. After searching all of the image file the program returns the coordinates of faces found in the
image.
6. The physical places of the faces in the image are recorded in order to ease next detection
job.
7. With the given coordinates the face images are cropped from the image and saved to another
location and sent to ‘Database and File Management Module’.
SACS SRS 2.0
33
3.2.3.2 Face Recognition Module
Brief Description
This function should take the pictures from the ‘database and file management module ’then
after necessary operations returns recognized faces.
Initial Step-By-Step Description
Some preprocessed face images should be available in the system in order to use this module.
1. The module takes the new coming and preprocessed face images from the ‘database and file
management’ module.
2. The system starts to take newly coming face image information and starts to compare with
the face database of students with the specific algorithms.
3. If a student image record matches with a face image, this is declared to ‘database and file
management’ module to record the student as present.
4. If a student image is not matched a student facial information in the database, then this face
information is reported to ‘database and file management’ module and this record is added to
database by this module.
3.2.3.3 Database and File Management Module
Brief Description
This module handles the database and file operations that take place between and along the
face detection and face recognition modules.
Initial Step-By-Step Description
1. After face detection operation this module should take the related image results.
2. After taking the image information this module should do necessary image processing
operations for a better face recognition.
3. Also this module controls database operations about client side of system.
4. After face recognition the module saves newly found students and also saves attendance
records to database.
SACS SRS 2.0
34
3.2.3.4 Error Correction Module
Brief Description
This function handles the reported face recognition errors.
Initial Step-By-Step Description
1. In some time intervals, errors that are reported by the user is checked by this module.
2. If there is a mismatch between records, the system will try to take last successful match
record from the database.
3. With the last successful record retrieved, this error will be tried to be handled.
4. If there is no successful record for mismatching, then it will renew the record of mismatched
student in next lectures of classrooms.
3.3 Non-functional Requirements
3.3.1 Performance requirements
Each of our servers should able to compute attendance of all classes in corresponding
school. All attendance reports can be checked after the server machine finishes the
computation of attendance. Cameras are able to send views of class that are have enough
resolution to recognize students.
3.3.2 Design constraints
When reporting, IEEE standards should be used and when drawing diagrams, UML
standards will be used.
4. Data Model and Description In this section of this document contains data description related diagrams and data
dictionary for these diagrams.
4.1 Data Description
In project all data will be held on servers database. These data are has type variety of
integer, texts, dates, Blob and indexes of these data. Binary large objects will be generally
image files.
SACS SRS 2.0
35
4.1.1 Data objects
Student data has some information about student. It consists of student address , id ,
name ,surname, set of student image that will be used in face recognition etc. Course data has
information of lesson hours, duration, placement, period, number of students, reference to class
student list etc. Class data has list of students that are enrolled to that course. Image data is
image file represented in database as a binary large object. Recognition data is xml file
information data will be used for identification: links between the taken images from camera and
the face recognition program. Detection data is xml file information data will be used for
detection of faces.
SACS SRS 2.0
36
4.1.2 Data dictionary
The data used are described and their connections are defined in the diagram below (Figure
27):
Figure 27: Data dictionary
SACS SRS 2.0
37
5. Behavioral Model and Description In this section of this document contains project data processing data-flow diagram,
state transition and user cases.
5.1 Description for software behavior
Our software product has client side and server side usages. At the client side, there will
be system users. When the system is ready to use, the users will be able to access the system.
They can use the SACS for facilitating the attendance checking. At the server side there will be
an operator. The system will be regulated and prepared by the operators. When the system is
ready to use the servers side will recognize the students with face detection. The images taken
with cameras will be operated in the server computer and will be compared with registered
students. Our product will operate and take images many times during the lecture to get certain
and more reliable results. The users will get the documents from server computer via internet.
5.2 State Transition Diagrams
Figure 28 shows the state transition diagram.
Figure 28: State Transition Diagrams
SACS SRS 2.0
38
6. Planning
6.1 Team Structure
Our team DeveloperCeng consists of four students:
Abdulaziz Aydoğmuş (1678770)
Akın Yılmaz (1679323)
Emre Deniz Özer (1679497)
İlker Yıldırım (1679315)
6.2 Estimation (Basic Schedule)
We plan to keep up with the Computer Engineering Design Course Syllabus. Our
schedule will be as close as the CENG 491 Course Schedule.
6.3 Process Model
We are using waterfall process model. In general, this model may be considered as
having six different phases:
1. Requirements Analysis
2. Design
3. Implementation
4. Testing
5. Installation
6. Maintenance
7. Conclusion In Conclusion, in this document, we have defined how SACS project should operate in
detail. These are the first plans about the project and during the implementation process; some
minor details may be changed or added. These changes will be shown in updated documents.