A CASE STUDY (IEEE Format)
Software Requirements Specification Document
Version 1.0
Access Control and Attendance Monitoring
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community
Ask the community for help and clear up your study doubts
University Rankings
Discover the best universities in your country according to Docsity users
Free resources
Our save-the-student-ebooks!
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Software Requirements for Access Control & Attendance System, Schemes and Mind Maps of Software Engineering
Template of srs and project file
Typology: Schemes and Mind Maps
2022/2023
1 / 20
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Software Requirements for Access Control & Attendance System and more Schemes and Mind Maps Software Engineering in PDF only on Docsity!
A CASE STUDY (IEEE Format)
Software Requirements Specification Document
Version 1.
Access Control and Attendance Monitoring
TABLE OF CONTENTS
3.2.3 Functional Requirements for Student cum Staff Welcome Screen
- Introduction Chapter No. Topic Page No.
- 1.1 Purpose of this Document
- 1.2 Scope of the Development Project
- 1.3 Definitions, abbreviations and acronyms
- 1.4 References
- 1.5 Overview
- Overall Description
- 2.1 Product Perspective
- 2.2 Product functions
- 2.3 User Characteristics
- 2.4 General Constraints, Assumptions and Dependencies
- 2.5 Apportioning of the requirements
- Specific Requirements
- 3.1 External Interface Requirements
- 3.2 Detailed Description of Functional Requirements
- 3.2.1 Functional Requirements for Student Welcome Screen
- 3.2.2 Functional Requirements for Staff Welcome Screen
- 3.3 Performance requirements
- 3.4 Logical database requirements
- 3.5 Quality attributes
- 3.6 Other requirements
- Change History
- Document Approvers
time a user is entering/ exiting the room/lab. For each swipe the time in/out will also be recorded and the total time spent in the lab will be computed by subtracting the time when user entered the lab with the time when the user came out of the lab. This will help the lab-in-charge to be aware of the time spent by the lab users even when the lab-in-charge is not physically present in the lab.
- Update access privileges: The software must be able to update the access privileges onto a particular userās card and the database where the privileges themselves will be modifiable only by the system administrators (or some authorized staff members).
- Determine access privilege levels: The software must be able to determine whether a particular user has been denied access from a particular lab due to some policy violation. The results of this operation will be viewable by the security officer only. Initially we plan to implement these functionalities for the 4 SDET unit labs with an intended audience of 60 people (of which 12 are staff members and remaining are students) as part of the Pilot Phase. Once the Pilot Phase is successful then we plan to implement it in other labs across the institute and eventually we plan to extend the CSC based Multi-Utility System including Access Control and Attendance Monitoring to a wide variety of applications including library system, semester fee payment system, etc. The scope of this system is not just limited to the university campus only as the same mechanism can be reused in other campuses as well. This system can also be implemented in the industrial sector where smart cards can take place of the Time Office system where a person sitting at the entrance notes down the time an employee entered the office and the time the person went out on break, came back and also the time when the person left the office in the evening. This scenario is prevalent in many industries today, with the notable ones being the cement, mining and other industries, although the same cannot be said of the IT companies as almost all the major software companies have already implemented smart card based access control mechanisms wherein the employee ID card doubles up as the smart card as well.
1.3 Definitions, abbreviations and acronyms
Definitions Table 1 gives explanation of the most commonly used terms in this SRS document. Table 1: Definitions for most commonly used terms S.No. Term Definition 1 Biometric Authentication Refers to technologies that measure and analyze human physical & behavioural characteristics for authentication purposes [1]. 2 Contactless Smart Card A second type is the contactless smart card, in which the chip communicates with the card reader through RFID induction technology (at data rates of 106-848 kbit/s). These cards require only close proximity to an antenna to complete transaction [2]. 3 ISO 14443 Itās a four-part international standard for contactless smart cards operating at 13.56 MHz in close proximity with a reader antenna. This ISO standard sets communication standards and transmission protocols between card and reader to create interoperability for contactless smart card products [4]. 4 ISO 7810 Describes the physical characteristics of different smart cards and also the overall dimensions of the card (along with ISO 7816-2) [5]. 5 ISO 7816 The basic contact smart card standard is the ISO 7816 series. These standards are derived from the identification card standards and detail the physical, electrical, mechanical, and application programming interface [5]. 6 Java Card A Java Card is a smart card capable of running programs written in Java. 7 MIFARE Itās a separate standard developed by NXP (formerly Philips Semiconductors) that closely models the ISO 14443A standard and is now widely used to develop contactless smart cards by NXP [6].
8 RFID Itās an automatic identification method, relying on storing and
[1]. Biometric Authentication Definition. Link: http://en.wikipedia.org/wiki/Biometrics [2]. Smart Card Definition. Link: http://en.wikipedia.org/wiki/Smart_card [3]. RFID Definition. Link: http://en.wikipedia.org/wiki/RFID [4]. ISO 14443 Introduction by OTI Global. Link: http://www.otiglobal.com/objects/ISO%2014443%20WP%204.11.pdf [5]. Won J. Jun, Giesecke & Derivent (G & D). July 8, 2003. āSmart Card Technology Capabilitiesā. PDF link: http://csrc.nist.gov/publications/nistir/IR-7056/Capabilities/Jun- SmartCardTech.pdf [6]. MIFARE website. Link: http://mifare.net/about/ [7]. Specifications for the Smart-Card OS for Transport Applications (SCOSTA) PDF Link: http://www.scosta.gov.in/SCOSTA_1.pdf [8]. NXP by Wikipedia. Link: http://en.wikipedia.org/wiki/NXP_Semiconductors [9]. Data Replication Strategies. A White Paper by Jay Orcutt, Data Management Architect, Sun Microsystems. PDF Link: http://www.sun.com/storagetek/white- papers/data_replication_strategies.pdf [10]. Data Replication Strategies in Grid Environments. Ewa Deelman, Information Sciences Institute, University of Southern California in collaboration with Houda Lamehamedi et al. Department of Computer Science, Rensselaer Polytechnic Institute. PDF Link: http://www.cs.rpi.edu/~szymansk/papers/ica3pp.02.pdf [11]. A Performance Study of Three High Availability Data Replication Strategies. David J. DeWitt, Computer Sciences Department, University of Wisconsin in collaboration with Hui-I Hsiao, IBM T.J. Watson Research Center. PDF Link: http://www.cs.wisc.edu/~dewitt/includes/paralleldb/pdis91.pdf
1.5 Overview
The remaining sections of this document provide a general description, including characteristics of the users of this project, the product's hardware, and the functional and data requirements of the product. General description of the project is discussed in section 2 of this document. Section 2 gives the functional requirements, data requirements and constraints and assumptions made while designing the multi-utility system. It also gives the user viewpoint of product use. Section 3 gives the specific requirements of the product. Section 3.0 also discusses the external interface requirements and gives detailed description of functional requirements.
2. Overall Description Functionality Related to
Components and
Deployment
Chapterization
2.1 Product Perspective
The product will run as a component of the smart card reader-writer device. The product does not require use of a pointing device or keyboard but it does require a small keypad with numbers 1-9 where each number represents a particular functionality that the user can avail. For example, by pressing 1, a faculty member (staff) can reserve 2 labs of IPC unit for 2 hours. Figure 1 shows the layout for SDET Unit's Microsoft Lab with the smart card reader- writer placed next to the lab entrance. Figure 1: SDET Unit Media Lab using Smart card based System Here the user will have to swipe his/her smart card against the reader-writer terminal and once the terminal identifies the card user by matching the cryptographic key generated by the software with the one generated by the card, the welcome message is displayed to the user. Next, the software inside the terminal will
modules:
- Card Identification
- Key Generator
- Display
- Transaction Upon swiping the card against the reader-writer device, the Card Identification Module will authenticate the card user by matching the ID No. / PSRN No. and the access code against the values stored in the central database server. The Card Identification Module in turn will call the Key Generator Module in order to obtain the key. The Key Generator Module will compute the key using some cryptographic algorithm and will return the value to the Card Identification Module. Once the card has been successfully identified the user will see a welcome message on the display screen similar to the message displayed in Figure 1 above. The Card Identification Module will thus send the card userās name to the Display module that will in turn print the welcome message onto the screen. Depending on the operation requested by the user (for example a faculty member may want to know how many students are present in the SDET Unitās Microsoft Lab or may want to reserve a room), the Display Module will call the Transaction Module with the respective operation. Here I have defined a transaction as a simple read /write operation where the data to be read / written may differ with each request. Thus a staff member trying to reserve a room for a test can be considered as a write transaction whereas a staff member trying to see number of students taking that test in the room on that particular date will be considered as a read transaction. The Transaction Module will thus process the read/write transaction and display the appropriate message back to the display screen by passing the message to the Display Module. In addition to the four modules, a Central database server and a Backup database server will also be used in order to read/write data onto the repository. The central database server will periodically update the Backup database server so that in case of server failure it can restore the data by retrieving the records stored in the Backup database serverās tables. I have enclosed the four modules in a grey
rectangle in order to indicate that these 4 modules comprise the major components of the CSC based Multi-Utility System software. And by showing a single arrow between the software and the central database server, I wish to convey the point that at a given point of time only one module within the software will communicate with the server database. That is, the card identification module and the transaction modules will not access the database at the same time as first a card has to be authenticated, following which the transactions can be processed.
2.2 Product Functions
The product should be able to perform the following operations:
- It must be able to authenticate the card user by matching the ID no. / PSRN no. and the access code against the values stored in the database.
- It must be able to check the lab/room status by querying the database for any reservation requests made earlier.
- It must be able to record the userās presence by writing the userās ID no. / PSRN no. in the corresponding database table. Thus for one swipe, two write operations will be performed: one into the central repository and other into the backup database server. For each swipe the time in/out will also be recorded and the total time spent in the lab will be computed by subtracting the time when user entered the lab with the time when the user came out of the lab.
- The software must be able to update the access privileges onto a particular userās card and the database where the privileges themselves will be modifiable only by the system administrators (or some authorized staff members).
- The software must be able to determine whether a particular user has been denied access from a particular lab due to some policy violation. The results of this operation will be viewable by the security officer only.
2.3 User Characteristics
Functional Requirements
The following list presents the constraints, assumptions, dependencies or guidelines that are imposed upon implementation of the CSC based Multi-Utility System including Access Control and Attendance Monitoring software: ļ· The software has to be integrated onto the reader-writer terminal that in turn has an extremely small form factor and has support for limited capability APIs only. ļ· Due to the small form factor, only limited graphics can be supported on the display screen. ļ· There are no memory requirements ļ· The product must have a user friendly interface that is simple enough for all types of users to understand. ļ· Response time for loading the software and for processing a transaction should be no longer than five seconds. ļ· A general knowledge of basic computer skills and of basic working of smart card based system is required to use the product. ļ· The central database server and backup database servers should be updated regularly. This updating and replication of data from central database server to the backup database server can introduce additional latency in the working of the system. ļ· The replication of data from central to the backup server has to be Asynchronous as Asynchronous solutions also provide a greater amount of protection by extending the distance between the primary and secondary locations of the data. Increased distances can provide protection from local events as the loss of a power grid, as well as natural disasters such as earthquakes and hurricanes [9]. Interesting work in this regard has been done by University of Wisconsin, Madison [11], University of Southern California and Rensselaer Polytechnic Institute, NY [10] scholars.
2.5 Apportioning of requirements
Progression of the Project and
Implementation of the
requirements
The CSC based Multi-Utility System (including Access Control and Attendance Monitoring) is to be implemented in the following three phases: i. Pilot Phase: Here the smart card based multi-utility system including access control and attendance monitoring will be implemented in the 4 SDET unit labs with the help of 60 smart cards and 4 reader-writers. Initially we will be providing access privileges for three types of users: student, staff and student cum staff as they will be ones most involved in this phase. ii. Institute wide deployment: Following the successful completion of the pilot phase, we plan to deploy the same across the. Biometric authentication will also come into the picture in this phase only, wherein small fingerprint sensors will be placed next to the server class machines inside the SDET Unit labs to start with. iii. Extension of smart card based multi-utility system to other applications: In the future we can have a single student smart card for example serving different purposes like purchasing a textbook at the Instituteās Co-operative store or paying the semester fees, an application that will really boost the utility value of the smart cards. Here the same functionalities will be implemented in each phase; the only difference will be the number of transactions being carried out and the scale of implementation.
3. Specific Requirements
Table 4: Functional Requirements for Student Welcome Screen Purpose This screen thus provides information specific to each student upon the successful identification of the ID no. and the access code with the values stored in the central database server. Inputs A student can view a page of information by choosing from one of the options given on the welcome screen. Selection is performed with a simple keypad. Processing The menu responds to selections by displaying a page containing the pre-defined text requested information. Outputs Output consists of a screen of information specific to a student. For example, as shown in Figure 1, upon choosing option ā2ā in the welcome menu, a student may be able to see the number of visits he made to the Microsoft lab in the last month.
3.2.2 Functional Requirements for Staff Welcome Screen
Table 5 gives the functional requirements for Staff Welcome Screen. Table 5: Functional Requirements for Staff Welcome Screen Purpose This screen provides information specific to each staff member. Inputs A staff member can view a page of information by choosing from one of the options given on the welcome screen. Selection is performed with a simple keypad. Processing The menu responds to selections by displaying a page containing the pre-defined text requested information. Outputs Output consists of a screen of information specific to a staff member and the students studying under him. For example, upon choosing option ā4ā in the menu displayed on the welcome screen, a faculty member may be able to see the number of students who have appeared for the CP 1 test being held in room 2201.
3.2.3 Functional Requirements for Student cum Staff Welcome Screen
Table 6 gives the functional requirements for Student cum Staff Welcome Screen.
Table 6: Functional Requirements for Student cum Staff Welcome Screen Purpose This screen provides information specific to each student cum staff. Inputs A student cum staff can view a page of information by choosing from one of the options given on the welcome screen. Selection is performed with a simple keypad. Processing The menu responds to selections by displaying a page containing the pre-defined text requested information. Outputs Output consists of a screen of information for student cum staff in terms of personal information with respect to the courses where the user is a student and information with respect to the students where the user is a staff member. For example, if a member of Economics group is also studying Object Oriented Programming and is also taking the Security Analysis and Portfolio Management course, then the member will be able to see data related to students taking the course Security Analysis and Portfolio Management and also see data relating to the course Object Oriented Programming in which he is a student.
3.3 Performance Requirements
ļ· The software is designed for the smart card reader-writer terminal and cannot run from a standalone desktop PC. ļ· The software will support simultaneous user access only if there are multiple terminals. ļ· Only textual information will be handled by the software. Amount of information to be handled can vary from user to user. ļ· For normal conditions, 95% of the transactions should be processed in less than 5 seconds.
3.4 Logical Database Requirements
Figure 3 shows the E-R diagram for the entire system.
Performance/ Deployment Based
Characteristics to be written here.
Performance of
software/hardware/database
The product is target towards a wide variety of users such as Student, staff, student cum staff, etc. The product must load quickly and work well on a variety of terminals. It must also tolerate wide variety of input possibilities from a user, such as incorrect responses or unforeseen keystrokes.
3.6 Other Requirements
None at this time
4. Change History
200209 Version 1.0 ā Initial Release
5. Document Approvers
SRS for CSC based Multi-Utility System (including Access Control and Attendance Monitoring) approved by:
(name) Designation Date: