Student biometric identification srs

Software Requirements Specification
Project:
Social Services Ranking (SSR)
Advisor:
Mr. Farhan
Co-Advisor:
Mr. Inam ul Haq
Submitted By:
Farhan Ali CIIT/SP13-BCS-009/Swl
Yasir Ali CIIT/ SP13-BCS-018/Swl
Azfar Tariq CIIT/ SP13-BCS-020/Swl
Submitted in partial fulfillment of the requirements of a Computer Science Final year
project
04-04-2016
Table of Contents
1 Introduction 3

P a g e | 2
1.1 Purpose 3
1.2 Scope 3
1.3 Definitions, Acronyms, and Abbreviations. 4
1.4 Overview 4
2 The Overall Description 4
2.1 Product Perspective 4
2.1.1 System Interfaces 5
2.1.2 User Interfaces 5
2.1.3 Hardware Interfaces 5
2.1.4 Software Interfaces 6
2.1.5 Communication Interfaces 6
2.1.6 Memory 6
2.1.7 Operation 6
2.1.8 Site adaption requirements 6
2.2 User Characteristics 7
2.3 Apportioning of Requirements. 8
3 Specific Requirements 8
3.1 Functional Requirements 6
3.2 Nonfunctional Requirements 7
3.3.1 Performance Requirements 7
3.3.2 Logical Database Requirements 7
3.3.3 Design Constraints 7
3.3.4 Standards Compliance 7
3.3.5 Reliability 7
3.3.6 Availability 7
3.3.7 Security 8
3.3.8 Maintainability 8
3.3.9 Portability 8

P a g e | 3
1 Introduction
The following subsections of the Software Requirements Specifications (SRS)
document provide an overview of the entire SRS.
1.1 Purpose
The Software Requirements Specification (SRS) will provide a detailed description
of the requirements for the Biometeric Student Identification (BSI). This SRS will
allow for a complete understanding of what is to be expected of the BSI to be
constructed. The clear understanding of the BSI and its’ functionality will allow for the
correct software to be developed for the end user and will be used for the development
of the future stages of the project. This SRS will provide the foundation for the project.
From this SRS, the BSI can be designed, constructed, and finally tested.
This SRS will be used by the software engineers constructing the BSI and the
organization end users. The software engineers will use the SRS to fully understand
the expectations of this BSI to construct the appropriate software. The organization
end users will be able to use this SRS as a “test” to see if the software engineers will be
constructing the system to their expectations. If it is not to their expectations the end
users can specify how it is not to their liking and the software engineers will change the
SRS to fit the end users’ needs.
1.2 Scope
The software product to be produced is a Biometric Student Identification which will
automate the major identification operations. The first subsystem is a Register a
user.The second subsystem is the identifying and verifying the users. The third
subsystem is an automatically sending a messae or mail when user enters and leaves
the organization. These three subsystems’ functionality will be described in detail in
section 2-Overall Description.
There are two end users for the BSI. The end users are the students and employees.
The Student Identification System ’s objectives is to provide a system to secure the
campus from outsiders or fake people. The system will be able to secure the Univeristy
from the outsiders in a quick manner. The system should be user appropriate, easy to
use, provide easy recovery of errors and have an overall end user high subjective
satisfaction.
1.3 Definitions, Acronyms, and Abbreviations.
SRS – Software Requirements Specification
BSI – Biometric Student Identifcation
Subjective satisfaction – The overall satisfaction of the system.
End users – The people who will be actually using the systems.
1.4 Overview
The SRS is organized into two main sections. The first is The Overall Description
and the second is the Specific Requirements. The Overall Description will describe the
requirements of the BSI from a general high level perspective. The Specific
Requirements section will describe in detail the requirements of the system.

P a g e | 4
2 The Overall Description
Describes the general factors that affect the product and its requirements. This section
does not state specific requirements. Instead it provides a background for those
requirements, which are defined in section 3, and makes them easier to understand.
2.1 Product Perspective
The BSI is a dependent system on CUOnline databsae.
2.1.1 System interfaces
The RMOS interfaces with an existing payment system, including a cash register and
software-accessible credit/EFTPOS system, in order to quickly and easily handle
customer billing. The payment system should be operable such that it can return
information to the RMOS system as to whether payment was successful or failed.
2.1.2 User interfaces
There is a single user interfaces used by the BSI software, related to an interfaced physical
hardware device (see Section 2.1.3).
Surface computer UI
The Surface Computer UI is the interface used by admin portal. This interface uses the
surface computer paradigm - admin interact with the system by key board, mouse and
display screen.
BioMeteric UI
The Biometeric UI is designed to accommodate customer needs. This UI will be
designed for use with a stylus input into the touch-screen. Because the number of
operations the UI needs to support is relatively limited, there will be no nested menu
structure. The UI shall provide simple graphical interfaces, similar to a map, to allow
the user to select tables/customers as the target of operations.
Display UI
The Display UI provides secuarity incharges to check the verification of the entering member.
The UI will display the information (such as Name, batch, picture and department) displayed
in tabulated format. Input is provided by finger print.
2.1.3 Hardware interfaces
The BSI will be placed on PC’s on the entry and exit points of the Univeristy.
2.1.4 Software interfaces
The BSI will interface with a Database Management System (DBMS) that stores the
information necessary for the BSI to operate. The DBMS must be able to provide, on request
and with low latency, data concerning the students and employees such as name, department,
picture and registration number. Additionally, it should take and archive data provided to it by
the BSI. This data will include records of all students and employees who entered in the

P a g e | 5
campus. The DBMS must store all data such that it can be used for accounting, as well as
accountability.
2.1.5 Communications interfaces
The BSI will interface with a Local Area Network (LAN) to maintain communication
with all its devices. It should use a reliable-type IP protocol such as TCP/IP or reliable-
UDP/IP for maximum compatibility and stability. All devices it will interface with
should contain standard Ethernet compatible, software accessible LAN cards to
maintain communication between the server and the surface computers.
2.1.6 Memory
The memory usage of the BSI will obviously have to be constrained by the devices it is
intended to run on. Memory constraints upon the server, surface computers and displays are
not likely to be an issue as each will likely have at least a gigabyte of primary memory and
hundreds of gigabytes or more of secondary memory.
2.1.7 Operations
The BSI has only one mode of operation. However, because of the university environment it
is used in, it must be able to operate for long periods, without error. The server must be able to
operate unattended indefinitely. It should not need physical interaction except for upgrades and
failure of hardware elements. Backup and recovery should be handled by the DBMS and
operating system, or external software running on a timed backup system. Interaction from the
BSI should not be required. Since stateful data should not be stored on any of the devices other
than the server, keeping a system image on the server for each device may be a sufficient
operational method to facilitate restoration should a device become corrupted.
2.1.8 Site adaptation requirements
Site configuration for the BSI is expected to encompass the following steps:
Install the server, surface computers and displays
Network all devices, install operating systems, server software and
DBMS Secure network, distribute initial passkeys
Install BSI software
Configure server BSI software
Some customisation of BSI software elements may be required, including:
Table layout maps
GUI elements, especially for students-facing UIs

P a g e | 6
2.2 User Characteristics
The end-users of the BSI fall into three primary categories, unskilled, partly skilled and highly
skilled.
Unskilled user
The users of the surface computers are walk-in students and should therefore be assumed to
have no relevant prior skills or education other than basic abilities to operate an automated
system; no more complex than a parking meter or vending machine.
Partly skilled user
They must be able to use the user interfaces except the server. Faculty and students also
fall into the same category, though they will have to learn other sections of the system.
Highly skilled user
The initial installation and configuration of hardware and the constituent SBI system
components (especially the server) is guaranteed to require someone with notable
computer experience, including extensive experience with network and operating
systems to complete it. The software should not be needlessly complex, but it is still
expected not to be entirely 'plug and play'. This class of user is expected to have a high-
school certificate or equivalent, as well as extensive computer experience.
2.3 Apportioning of Requirements
This subsection pertains to both the functional and non-functional requirements omitted
unintentionally from this SRS document.
3 Specific Requirements
This section contains all the software requirements at a level of detail, that when
combined with the system context diagram, use cases, and use case descriptions, is
sufficient to enable designers to design a system to satisfy those requirements, and
testers to test that the system satisfies those requirements.
3.1 Functional Requirements
This subsection presents the identified functional requirements for the subject SBI.
Initially, general requirements that pertain to the whole system are given. Where
possible, subsequent requirements have been demarcated based on their relevance to
the users of the system, that is, students,employee and administrator.
3.1.1 General
Following are the identified functional general requirements that directly relate to the
entire subject SBI.

P a g e | 7
 A server shall host the SBI and provide system data processing and storage capability.
 A surface computer shall provide student information.
 A display shall provide a chef with all chef system functionality.
External Interfaces
The Social Services Ranking will use the standard input/output devices for a
personal computer. This includes the following:
Internet
Keyboard
 Mouse
 Monitor
3.1.1 User Interfaces
The User Interface Screens are described in table 1.
Table 1: Student Biometric Identification
Screen Name Description
Login Log into the system as a admin, member or service provider.
Dashboard Dashboard will be different for users, admin will
approve/reject/block/resume service providers registration on
dashboard. Service provider can manage their page and can check
inbox messages. Members can watch all the services here.
Registration This screen will capture necessary information of member
registration and service provider’s registration. Both have different
screens.
Contact us Contact us screen will give information about each service
providers.
Admin Panel Admin can approve, reject , block and resume the service
providers’ profile.
3.1.2 Software Interfaces
All databases for the BSI will be configured using SQL Database 2012. This database
include students and employees information. This can be modified by the
administrator. The users (Students and employees) database will include the name,
registration number, phone number, mailing address, check in & out time and biometric
finger prints
3.1.3 Hardware Interfaces
The BSI will be placed on PC’s on the entry and exit points of the Univeristy.
3.1.4 Communication Interfaces
HTTPS protocol will be used to communicate between clients and server.
3.2 Functional Requirements
Functional requirements define the fundamental actions that system must perform.
The functional requirements for the system are divided into three main categories,
Registration, Admin panel and Reporting. For further details, refer to the use cases.

P a g e | 8
1. Registration
1.1.The system shall record the member’s first name.
1.2.The system shall record the member’s last name.
1.3.The system shall record the member’s gender.
1.4.The system shall record the member’s Age.
1.5.The system shall record the service provider’s organization name.
1.6.The system shall record the service provider’s category.
1.7.The system shall record the service provider’s address.
1.8.The system shall record the service charges of service providers.
1.9.The system shall record the service provider’s contact information.
1.10. The system shall record the service provider’s working hours.
2. Admin Panel
2.1.The admin panel shall only accessed by administrator.
2.2.The system shall record the data of daily enteries.
2.3.The system shall add the students.
2.4.The system shall approve student or employee.
2.5.The system shall reject the student or employee.
2.6.The system shall let admin block the existing student or employee profile.
2.7.The system shall let admin resume the blocked student or employee profile.
2.8. The system shall manage all the students and employees.
3. Reporting
3.1.The system shall display the list of current day members who entered in the
campus.
3.3 Non Functional Requirements
Non Functional requirements define the needs in terms of performance, logical database
requirements, design constraints, standards compliance, reliability, availability,
security, maintainability, and portability.
3.3.1 Performance Requirements
Performance requirements define acceptable response times for system functionality.
 The load time for user interface screens shall take no longer than two seconds.
 The log in information shall be verified within five seconds.
 Queries shall return results within three seconds(Member will be identified with
in three seconds).
3.3.2 Logical Database Requirements
The logical database requirements include the retention of the following data elements.
This list is not a complete list tables of and is designed as a starting point for
development.
 Members
 Service Categories

P a g e | 9
 Services
 Locations
 Notifications
 Service Ratings
 Service Comments
3.3.3 Design Constraints
The Student Biometeric Identification System (SBI) shall be a stand-alone system
running on a server Windows environment. The system shall be developed using
ASP.NET and MS SQL server database.
3.3.4 Standards Compliance
There shall be consistency in variable names within the system. The graphical user
interface shall have a consistent look and feel.
3.3.5 Reliability
Specify the factors required to establish the required reliability of the software system
at time of delivery.
3.3.6 Availability
The system shall be available for 24 hours.
3.3.7 Security
Service providers can log in to the Student Biometeric Identification System. Service
providers have access to the admin panel on which they can manage the student and
teachers database. They can approve or reject the new registration of students and
teachers against the business rules. Students or teachers can use biometric device only
for identification purpose.
3.3.8 Maintainability
The Student Biometeric Identification (SBI) is being developed in MATLAB and C#
language. C# is an object oriented programming language and shall be easy to maintain.
3.3.9 Portability
The Student Biometeric Identification (SSR) shall run on specific Systems.

Student biometric identification srs

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to Student biometric identification srs

Similar to Student biometric identification srs (20)

Recently uploaded

Recently uploaded (20)

Student biometric identification srs