Se-10 Se-11 Sre Srs Assignment

Software Requirement Specification for Biometric Attendance System
NED University of Engineering & Technology – Department of Software Engineering
ROLES
Farzeen Zehra (SESE-19011)

Responsible for:
● Identifying users and their roles
● Analyzing product perspective
● Stating the software user interface, and hardware requirements
● Collecting Functional requirements
● Gathering the logical database requirements
● Defining the constraints on the system
● Creating class diagram
● Creating Block level diagram to show the context of system
● Managing Appendix
Darakhshan (SESE-19010)
Responsible for:
● Collecting domain knowledge
● Defining the purpose, scope , goals and benefits
● Stating communication and software interface requirements
● Describing the overall description of system
● Stating the software system attributes
● Analyzing the user and their characteristics
● Stating constraints, assumptions and dependencies of the system
● Analyzing product functionality
● Making use case diagram to show user’s interaction with the system
● Collecting non-functional requiremnets
● Managing Index
1
Software Requirements
Specification
for
Biometric Attendance System

Version 1.0
Prepared by
Farzeen Zehra SE-19011 zehra4204482@cloud.neduet.edu.pk

Darakhshan SE-19010 darakhshan4200300@cloud.neduet.edu.pk
Instructor: Dr. Shehnila Zardari

Date: January 20,2020
2
Table of Contents
1. Introduction 5
1.1. Purpose 5
1.2. Scope 5
1.2.1. Description 5
1.2.2. Benefits 5
1.2.3. Goals 5
1.3. Definitions, acronyms, and abbreviations 6
1.4. References 6
1.5. Document Overview 6
2. Overall Description 7
2.1. Product Perspective 7
2.2. Product functionality 7
2.3. Users And Characteristics 8
2.3.1. Admin 8
2.3.2. Teacher 9
2.3.3. Student and staff 9
2.4. Constraints 9
2.5. Assumptions and Dependencies 9
2.5.1. Assumptions 9
2.5.2. Dependencies 9
3. Specific Requirements 10
3.1. External Interface Requirements 10
3.1.1. User Interfaces 10
3.1.1.1. Interface Design 10
3.1.1.2. Ease of Use 10
3.1.1.3. Responsiveness 10
3.1.2. Hardware Interfaces 10
3.1.3. Software Interfaces 10
3.1.4. Communication Interfaces 11
3.2. Functional Requirements 11
3.2.1. For Admin, Students, Teacher, and Staff Members: 11
3.2.1.1. Functional Requirement 1.1 11
3

3.2.2. For Students, Teachers, and Staff Members: 12
3.2.3. For Admin 12
3.2.4. For Teacher 13
3.3. Non-Functional Requirements 13
3.3.1. Performance Requirements 13
3.3.2. Software System Attributes 14
3.3.2.1. Reliability 14
3.3.2.2. Maintainability 14
3.3.2.3. Security 14
3.3.2.4. Availability 14
3.3.2.5. Portability 14
3.4. Logical Database Requirements 14
3.5. Design Constraints 15
Appendix 16
Glossary 16
Index 17
4
1. Introduction
1.1. Purpose
The purpose of this document is to present a complete description of the Fingerprint based
attendance management system. The document briefly explains what is the purpose and features
of the system, how the interface looks like, how the system is handled and under what constraints
the system will operate. The SRS will describe a complete picture of how the academic
institutions will avail the facility of automated attendance and recognize them through their
fingerprints and mark them present in the database automatically.
The intended audience who read this SRS are system developers and administration of
educational institutions.
1.2. Scope
1.2.1. Description
A biometric technology is a web-based system that is used to provide a secure and time saving
attendance marking method. An attendance marking device records attendance through
fingerprint reader. Students, teachers and staff members will mark their attendance through a
fingerprint reader device. Their presence is marked in the database and updated on the website.
User's attendance reports are generated on a monthly basis.This system stores and fetches the
data about the user such as present or absent in the cloud database.
1.2.2. Benefits
The result of this system is very fruitful for the educational institutions as it helps in keeping the
data of user’s attendance.All the issues related to manual attendance procedure can be tackled
through this attendance procedure. Teachers just need to log in to the website to track and
manage the student’s attendance. Moreover, students will not be able to mark each other's
attendance.
1.2.3. Goals
The main target goals of this system are as follows:
➔ To improve the current paper-based attendance system

➔ To deal with errors occurred in recording the attendance manually.
➔ In case,if the attendance sheet is missed, there is no chance of backup loss of attendance
records.
➔ To make the attendance system safe by reducing the chance of forgery in which one
person marks the attendance of the others.
➔ To stop delays in marking the attendance.
➔ To save the time of teachers.
5
1.3. Definitions, acronyms, and abbreviations

The definitions, acronyms, and abbreviations are all mentioned in Appendix (Glossary).
Furthermore, the standard glossary of software engineering[1] can be used to understand this
document.
1.4. References
[1] "IEEE Standard Glossary of Software Engineering Terminology," in IEEE Std
610.12-1990 , vol., no., pp.1-84, 31 Dec. 1990, doi: 10.1109/IEEESTD.1990.101064.
[2] R. Cardin, “Calculating Dependency,” 14-Apr-2017. [Online]. Available:

https://dzone.com/articles/dependency. [Accessed: 20-Jan-2021]
[3] "IEEE Recommended Practice for Software Requirements Specifications," in IEEE Std
830-1998 , vol., no., pp.1-40, 20 Oct. 1998, doi: 10.1109/IEEESTD.1998.88286.
1.5. Document Overview

This SRS is organized as follows:
Section 2 describes the overall description of software. It consists of details of product

perspective, product functions, user classes and characteristics, some general constraints that
must be kept in consideration while making the software and some assumptions and
dependencies that are assumed to be applied and on which our system depends respectively.
Section 3 describes the most important features of software. It consists of specific requirements
which are expected to be delivered by the software. This section comprises external interface
requirements with respect to users, hardware, software and communication. It also includes
functional requirements and non-functional requirements. This section is specifically written for
developers as it describes technical terms and functions related to product.
This document is formatted according to IEEE standard for Software Requirements

Specifications[3].
6
2. Overall Description
2.1. Product Perspective
This biometric attendance system will be used by university administration. This system interacts
with the university management system to get the user information for authentication and to
provide fingerprint data for enrollment of new students, teachers, or staff members.
Figure 1. - Block Diagram
2.2. Product functionality

➔ Admin manages the whole attendance system. He can respond to the request of a newly
enrolled teacher or student. He can view the whole attendance record. He can grant view
access to others
➔ There are multiple fingerprint reader devices installed in the whole university that can
take the fingerprint of all users individually and record them as present in the database.
All the devices are linked with the attendance system
➔ All those users who are not recognized on a particular date through their fingerprints can
be automatically marked as absent.
➔ Whenever a user is logged in, the system matches his credentials from the database to
ensure the validity and then give access.
➔ Students and staff faculty can view their attendance record and also download the
attendance report in the pdf form.
7
➔ Teachers also avails the facility to view the attendance of record of all students in their
respective subjects.
Figure 2. - Use Case Diagram
2.3. Users And Characteristics

2.3.1. Admin
Admin manages the whole system. He has access to all the devices installed in the university and
can grant access to anyone he wants. He can view the attendance record of all teachers, faculty
staff and students at any time.
8
2.3.2. Teacher
The person who teaches in the university. They can mark their own attendance and can check the
student’s attendance record in his course
2.3.3. Student and staff

Staff faculty members are the non-teaching staff of the university. Students and faculty staff
members also mark their attendance and check records on a daily or monthly basis.
2.4. Constraints
Followings are some general limitations under which software will work.
a) Regulatory Policy: The website should be in accordance with the institution's

policy.
b) Hardware Limitations: For fast and accurate results, a fingerprint reader device
of high quality sensor detector should be used.
c) Browser Limitation: The version of chrome should be 84.X or greater.
d) Interface to other requirements:System database must be compatible with
student management system and teacher management system database.
e) Memory Limitations: Cloud storage should be 8GB or greater.
f) Availability Limitations: Cloud should be available 99.99% of time
g) Reliability Limitations: There must be admin’s fingerprint authentication so that
no unauthorized person can be able to access the device.
h) Safety and security Limitations: Record must be saved in database cloud in the
encrypted form so that security of record is maintained
2.5. Assumptions and Dependencies

2.5.1. Assumptions
➔ We assume that this website is accessible to the users inside the university
premises.
➔ We assume that users will mark attendance with clean fingers for easier detection
2.5.2. Dependencies
➔ This software depends on network availability and LAN connection. Without this,
the website can not be able to respond to the events.
➔ System is dependent upon the fingerprint reader device. Without this device, it is
unable to work.
➔ The attendance system depends upon the university management system for data
requirements.
➔ It also depends on the way the admin handles the website.
9
3. Specific Requirements
3.1. External Interface Requirements
3.1.1. User Interfaces
3.1.1.1. Interface Design
➔ For All Users

● A login panel to authenticate users. The user will enter username and password. If
both are correct then the access is granted to the system.
● A dashboard which is customizable as per user’s wish. By default, it shows
current month attendance.
➔ Specifically For Admin:
● A settings page to enable or disable the system. The admin can also provide
access to attendance viewing to any other user.
● Attendance Report page to generate attendance report for any student, teacher, or
staff member.
➔ Specifically for Teacher:
● Attendance Report page to generate and view his/her attendance report.
● Student’s Attendance page to generate and view his/her current students
attendance.
➔ Specifically for Student and Staff Members:
● Attendance Report page to generate and view his/her attendance report.
3.1.1.2. Ease of Use
➔ It should be easy to use such that any user requires only 1 hour of training to use it.
3.1.1.3. Responsiveness
➔ The website should be responsive and should be viewed correctly from 320px to 1024px.
3.1.2. Hardware Interfaces

Multiple fingerprint scanners will be connected to the biometric attendance system. The
ZKTeco Zk4500 fingerprint scanner must be used to scan fingerprints.
3.1.3. Software Interfaces

This system should integrate with:
➔ ZKFinger SDK 5.3 to connect the fingerprint scanner to the system and pass instructions
to the scanner.
➔ Existing University Management System to fetch data about users.
10
➔ Attendance database to store the attendance data of all users

➔ The users require a web browser and working internet connection to connect to the
system. The browser should be:
● chrome 87.x or greater
● firefox 84.x or greater
3.1.4. Communication Interfaces

➔ The system should use a local area network to connect to the existing university
management system.
➔ The website should be in accordance with HTTPS protocol.
➔ The Advanced Encryption Standard (AES) should be used to encrypt the database.
3.2. Functional Requirements

3.2.1. For Admin, Students, Teacher, and Staff Members:
These requirements are for all users ( admin, students, teachers and staff members)
3.2.1.1. Functional Requirement 1.1
ID: FR-1
Name: Login
Description: The user enters credentials (username and password) onto the login page.
The system validates the user. Access is provided. Website opens.
Exception: If the credentials are not correct, then an error message is shown.
ID: FR-2
Name: Customizing Dashboard
Description: The user can change:
● the colour of dashboard
● the chart type that shows current month attendance
Exception: None
ID: FR-3
Name: Export Attendance Report
Description: The admin clicks the export attendance report button. The attendance report
is downloaded in pdf format.
Exception: None
11
ID: FR-4
Name: Logout
Description: The user clicks the logout button. The account of that user closes. Back to
the login page.
Exception: None
3.2.2. For Students, Teachers, and Staff Members:

These requirements are for students, teachers, and staff members
ID: FR-5
Name: View my attendance
Description: The user clicks on the view my attendance button. The attendance report is
generated and available to view. The user views his attendance report.
Exception: None
ID: FR-6
Name: Mark Attendance
Description: The user scans his fingerprint. The attendance is marked. Success message
is shown.
Exception: None
3.2.3. For Admin

These requirements are specifically for admin.
ID: FR-7
Name: View Attendance of student, teacher, and staff member
Description: The admin clicks the view attendance button. The attendance report page
opens with a search field. Admin types the ID or username of the user to search the
record.The website shows search results. The admin selects the particular user. Report is
generated and available to view. Admin views the attendance report.
Exception: If no user is available with that username or id then it shows message “No
such user”
ID: FR-8
12
Name: Enable/Disable the fingerprint devices

Description: The admin can turn the fingerprint scanners on and off.
Exception: None
ID: FR-9
Name: Provide access of view attendance to other users
Description: The admin clicks on the grant access button. A form appears with
username, id and duration for which access is granted. The admin clicks the submit
button. Success message shows. Access is granted.
Exception: If access is already granted to that user, it shows a message that the access is
already granted to the user.
3.2.4. For Teacher

These requirements are specifically for teachers.
ID: FR-10
Name: View Student Attendance Report
Description: The teacher clicks view students’ attendance report button. The attendance
report page opens with a search field. Teacher types the ID or username of the student to
search the record. The website shows search results. The teacher selects the particular
student. Report is generated and available to view. Teacher views the attendance report.
Exception: None
3.3. Non-Functional Requirements

3.3.1. Performance Requirements
➜ The website should be available for use 24x7.
➜ The fingerprint reader device should be activated in less than 1 second.
➜ The device should be ready for taking the fingerprint of every next individual within 10
seconds.
➜ Records should be updated in cloud storage in less than 2 second.
➜ Retrieving the data from the existing management system and matching it with the
credentials of logged in users should take a maximum of 1 second.
➜ Display screen should respond to the user's request (admin or teacher request to view the
record) within 5 seconds.
13
3.3.2. Software System Attributes

➜ 3.3.2.1. Reliability
● The failure rate should be 1 per 3 months.

● The website should give 100% search results.
● MTTR should be less than 3 hours.
➜ 3.3.2.2. Maintainability
● The degree of dependency[2] should be less than 0.3. Less dependency leads to
easy maintenance.
● Since the system is developed using an object-oriented programming language so
all the components should be independent and should be tested independently.
Their test coverage should be more than 98%
➜ 3.3.2.3. Security
● Only authenticated users should be able to use the website with their unique login
ids.
● Data should be stored in encrypted form.
➜ 3.3.2.4. Availability
● The website should be active 99.99% of time and available for the users.
➜ 3.3.2.5. Portability
● The website should be portable on mobile, laptop, PC and tablets etc.
3.4. Logical Database Requirements

The system will be integrated with a database to store attendance records. This data will include
full name, username, email, phone number, age, userid, password and date of birth for all users.
The student will have some more fields such as roll number, semester, year, and batch. The
teacher and staff member will have extra fields of salary and designation. The relationship
between the classes in this software are shown in the diagram below (Figure 3.). It shows that the
admin, teacher, staff member, and student are inherited from the abstract user class. The user
class is associated with a dashboard that will show the current month attendance written as well
as graphically. Each user can have one or more fingerprints stored into the system. Each user can
view and download the attendance report which consists of multiple attendance records. Each
attendance record is of a particular class whereas that each class is of a particular course. For this
system, the database will store string, int, long, date and time type of data. Given below is a class
diagram that shows a clear view of software database requirements.
14
Figure 3. - Class Diagram
3.5. Design Constraints

➔ Internet speed of at least 1mb/s is required to access the website.
➔ The website protocols should comply with university policy.
➔ The website should work properly on chrome 87.x or greater and firefox 84.x or greater.
15
Appendix
Glossary
A
Administration………………….…The heads of organization
AES…………………………….…Advanced Encryption Standard to encrypt database
Authentication…………………….The act of confirming or validating something
Automated……………………...…Operated by machines or equipments
Availability………………………..The quality of a software to remain available to users for use
B
Biometric………………………….A characteristic or method to identify humans digitally
Browser…………………...……….A desktop software to get access to websites
C
Cloud……………………………...Data storage on internet
Chrome………………………....…A web browser offered by Google
Compatible……………………......When two softwares can work together, they are compatible
Constraints………………………...Limitations or restriction on the system that restricts the
solution that can be provided for software
Credentials………………………...The data that is unique to each user and used for his
verification
D
Dashboard…………………………A page that contains all the information at one place and
usually contains graph to represent data graphically
Database…………………………...A way of storing data into file which is organized and
uniquely identified
Dependency………………………..A software uses other software components
E
Exception…………………………..A condition that stops the flow of program
Export……………………………...To download
F
Fingerprint scanner………………...A device used to read the fingerprint
H
HTTPS……………………………..Hypertext Transfer Protocol Secure
I
Interface…………………………....A medium through which user interacts with the computer
program
L
LAN………………………………..Local Area Network
M
16
Maintainability…………………….A software is maintainable if the software components can

be easily managed, errors can be corrected easily, and components can be modified without too
much effect on the system
P
Portability………………………….The ease with which the software can be transported to
other platforms
R
Regulatory Policy………………….Any policy of that controls the activities or specifically the
way a software is built or the method it uses in case of software
Responsiveness…………………….The design that can be used correctly with text overflow on
multiple devices
U
University premises………………...The area that is owned by the university
V
Validity………………...……....…...The state of being correct
17
Index
A
Administration………………………………………………………………...Page 4,6
AES…………………………………………………………………………….Page 8
Authentication………………………………………………………………...Page 5, 6
Availability……………………………………………………………..……...Page 6, 7, 11, 12
B
Biometric………………………………………………………………………Page 1,2,6,9
Browser………………………………………………………………………..Page 8,10
C
Chrome………………………………………………………………………...Page 8,10,14
Cloud…………………………………………………………………………..Page 4, 6, 11, 12
Compatible…………………………………………………………………….Page 8
Constraints…………………………………………………………………….Page 4, 5, 6, 12
Credentials…………………………………………………………………….Page 5, 8, 11
D
Dashboard……………………………………………………………………..Page 9,10,13
Database……………………………………………………………………….Page 4, 5, 6, 8, 12
Dependency…………………………………………………………………....Page 5,13
E
Exception……………………………………………………………………....Page 10,11,12
Export………………………………………………………………………….Page 10,11
F
Fingerprint Scanner…………………………………………………………..Page 9, 10,12
H
HTTPS…………………………………………………………………………Page 8
M
Maintainability………………………………………………………………...Page 11
P
Portability……………………………………………………………………...Page 11
R
Regulatory Policy……………………………………………………………...Page 8
Responsiveness…………………………………………………………………Page 9
U
University premises……………………………………………………………Page 9
V
Validity………………………………………………………………………….Page 7
18

Se-10 Se-11 Sre Srs Assignment

Uploaded by

Document Information

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

Se-10 Se-11 Sre Srs Assignment

Uploaded by

Copyright:

Available Formats

Software Requirement Specification for Biometric Attendance System

NED University of Engineering & Technology – Department of Software Engineering

Farzeen Zehra (SESE-19011)

Biometric Attendance System

Farzeen Zehra SE-19011 zehra4204482@cloud.neduet.edu.pk

Instructor: Dr. Shehnila Zardari

3.2.1.4. Functional Requirement 1.4 12

➔ To improve the current paper-based attendance system

1.3. Definitions, acronyms, and abbreviations

[2] R. Cardin, “Calculating Dependency,” 14-Apr-2017. [Online]. Available:

1.5. Document Overview

Section 2 describes the overall description of software. It consists of details of product

This document is formatted according to IEEE standard for Software Requirements

Figure 1. - Block Diagram

2.2. Product functionality

Figure 2. - Use Case Diagram

2.3. Users And Characteristics

2.3.3. Student and staff

a) Regulatory Policy: ​The website should be in accordance with the institution's

2.5. Assumptions and Dependencies

➔ For All Users

3.1.1.2. Ease of Use

3.1.2. Hardware Interfaces

3.1.3. Software Interfaces

➔ Attendance database to store the attendance data of all users

3.1.4. Communication Interfaces

3.2. Functional Requirements

3.2.1.1. Functional Requirement 1.1

3.2.1.2. Functional Requirement 1.2

3.2.1.3. Functional Requirement 1.3

3.2.1.4. Functional Requirement 1.4

3.2.2. For Students, Teachers, and Staff Members:

3.2.2.1. Functional Requirement 1.1

3.2.2.2. Functional Requirement 1.2

3.2.3. For Admin

3.2.3.1. Functional Requirement 1.1

3.2.3.2. Functional Requirement 1.2

Name:​ Enable/Disable the fingerprint devices

3.2.3.3. Functional Requirement 1.3

3.2.4. For Teacher

3.2.4.1. Functional Requirement 1.1

3.3. Non-Functional Requirements

3.3.2. Software System Attributes

● The failure rate should be 1 per 3 months.

● The website should be portable on mobile, laptop, PC and tablets etc.

3.4. Logical Database Requirements

Figure 3. - Class Diagram

3.5. Design Constraints

Maintainability​…………………….A software is maintainable if the software components can

You might also like

a) Regulatory Policy: The website should be in accordance with the institution's

Name: Enable/Disable the fingerprint devices

Maintainability…………………….A software is maintainable if the software components can