












Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
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 for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Template of srs and project file
Typology: Schemes and Mind Maps
1 / 20
This page cannot be seen from the preview
Don't miss anything!
3.2.3 Functional Requirements for Student cum Staff Welcome Screen
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.
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].
[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
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.
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:
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.
The product should be able to perform the following operations:
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.
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.
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.
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.
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.
ļ· 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.
Figure 3 shows the E-R diagram for the entire system.
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.
None at this time
200209 Version 1.0 ā Initial Release
SRS for CSC based Multi-Utility System (including Access Control and Attendance Monitoring) approved by:
(name) Designation Date: