Research Paper, 21 pages (5000 words)

Srs of library management

Subjects: Business, Management

Info

Published: November 14, 2021
Updated: November 14, 2021
University / College: Carnegie Mellon University
Language: English
Downloads: 45

Catalan | | Course & Year: | BS in InformationTechnology3 | | Schedule: | TTH 7: 30 – 9: 00 AM | | Date: | April 16, 2013 | | | | Table of Contents title pagei table of contentsii table of figuresiii Revisionsiv 1Introduction5 1. 1Document Purpose5 1. 2Product Scope5 1. Definitions, Acronyms and Abbreviations5 1. 4References6 1. 5Overview6 2Overall Description7 2. 1Product Perspective7 2. 2Product Functionality8 2. 3Users and Characteristics8 2. 4Operating Environment9 2. 5Design and Implementation Constraints9 2. 6User Documentation10 2. 7Assumptions and Dependencies10 3Specific Requirements11 3. 1External Interface Requirements11 3. 1. 1User Interfaces…………………………………………………………………………………………… 14 3. 1. 2Hardware Interfaces…………………………………………………………. ……………………….. 14 3. 1. 3Software Interfaces……………………………………………………………………………………… 14 3. 1. 4Communication Interfaces…………………………………………………………………………….. 15 3. 2Functional Requirements………………………………………………………………………………………………… 15 3. 2. 1Librarian Use Cases……………………………………………………………………………………. 5 3. 2. 2Clerk Use Cases…………………………………………………………………………………………. 19 3. 2. 3Borrower Use Cases……………………………………………………………………………………. 24 4Other Non-functional Requirements27 4. 1Performance Requirements27 4. 2Safety and Security Requirements27 4. 3Software Quality Attributes28 4. 3. 1Functionality……………………………………………………………………………………………… 28 4. 3. Usability……………………………………………………………………………………………………. 28 4. 3. 3Reliability………………………………………………………………………………………………….. 28 4. 3. 4Supportability…………………………………………………………………………………………….. 28 Appendix A – Data Dictionary. 30 Appendix B – Group Log. 31 InDEX. 33 Table of Figures Figure 1 Context diagram7 Figure 2 Operating environment9 Figure 3 Main interface11

Figure 4 Logging station for Librarian12 Figure 5 Clerk station for connection13 Figure 6 Clerk station14 Librarian Use Cases15 Log in………………………………………………………………………………………………………………… 15 Log out……………………………………………………………………………………………………………….. 16 Search book……………………………………………………………………………………………………….. 6 Issue book………………………………………………………………………………………………………….. 17 Update database…………………………………………………………………………………………………. 18 Clerk Use Cases19 Log in………………………………………………………………………………………………………………… 19 Log out……………………………………………………………….. ……………………………………………. 9 Search book ………………………………………………………………………………………………………. 20 Issue book………………………………………………………………………………………………………….. 21 Return book……………………………………………………………………………………………………….. 21 Add book…………………………………………………………………………………………………………… 2 Update database…………………………………………………………………………………………………. 23 Borrower Use Cases24 Log in…………………………………………………………………………………………………………………………… 24 Borrow book………………………………………………………………………………………………………………….. 24 Return book………………………………………………………………………………………………………… 5 Revisions | Version | Primary Author(s) | Description of Version | Date Completed | | 1. 2 | Jun Jun G. Abanag, Jude | The revision of this SRS was done by request. Error | 04/16/13 | | | Marlon B. Alegro | corrections to some parts of the document were needed to fully| | | | | complete an accurate Software Requirements Specification.

Some| | | | | specified features were removed because it was uncompleted due| | | | | to lack of time and preparation. Some small details in | | | | | chapters were also corrected and Content page was revised. | | | | | Finally, to finish the SRS, then Appendix B and Index were | | | | | added. | Introduction 1 Document Purpose This Software Requirements Specification will provide a complete description of all the functions and specifications of the project, A-Flex Automated Library Management System. It will explain the purpose and the features of the system, the interface of the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. This document is intended for both of the stakeholders and the developers of the system and will be proposed to the College Library of Samar College. Product Scope The A-Flex Automated Library Management System will be designed for the librarian, the staff and clerks and especially for the students of SC Library to maximize their productivity by providing tools to assist in automating the: production and transaction; logging in; monitoring materials; borrowing and returning of books and other library materials; assessing the overdue; inventorying; and creation of statistics and reports, which otherwise have to be performed manually in an ordinary daily basis.

More specifically, this system will allow a certain user to manage, organize and monitor the data and attendance of the clerks, the status of the books and other library properties and the library records of the registered students to the library. Nevertheless the access to these capabilities will depend on the user privilege of an account. It will automatically provide statistical reports based on the data stored in its associate database which is updated consistently. Therefore the software will give an ease to do these tasks that are vital in managing the library. Definitions, Acronyms and Abbreviations | Term | Definition | | Borrower | Any person who wishes to borrow books inside the school library. | | Clerk | Any person who assists the librarian in minor tasks needed performed inside the library. | | Database | A collection of all data produced by the system. | | Librarian | A person who is assigned responsible in generally managing the school library. | QR Code | Quick Response code, a type of bar code/encrypted code that will be used for the project in identification | | | purposes. | | Requirements | Refers to the “ what” the product has to do, not the “ how” it is be done. | | SC | Abbreviation of the name of the school where the system will be proposed. The Samar College | | SRS | Software Requirements Specifications.

A document that completely describes all of the functions of a proposed| | | system and the constraints under which it must operate. For example, this document. | | Stakeholder | Any person with an interest to the project but is not a developer. | | User | Any person who operates or interacts directly with the product. | | VB | Visual Basic, a building/programming software used in creating the system | | XAMPP | An application used to have a connection between the product and its database. 4 References IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998. [IEEE] The applicable IEEE standards are published in “ IEEE Standards Collection,” 2001 edition. [Bruade] The principal source of textbook material is “ Software Engineering: An Object- Oriented Perspective” by Eric J. Bruade (Wiley 2001). [Reaves SPMP] “ Software Project Management Plan Jacksonville State University Computing and Information Sciences Web Accessible Alumni Database. ” Jacksonville State University, 2003. 5 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, Requirements Specification 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. Overall Description

This section provides a more detailed overview of the system, including a description of the product’s functions and overarching constraints. 1 Product Perspective A – Flex Automated Library Management System Figure 1 – Context diagram As shown in the Figure 1, A-Flex Automated Library Management System (A-Flex ALMS) is independent from other system and has three active actors and one database (where all information is stored and retrieved from). The Borrower, Clerk and the Librarian have a privilege to access the library system. However, the Librarian alone has the privilege to access the database, i. e. eleting, updating and/or adding such records and making reports. A-Flex ALMS uses Interaction Model, a Use Case Diagram, to make stakeholders easily view the system operation. 2 Product Functionality The product has the following major functionalities: • Automated logging in of students into the library • Automated borrowing and returning of books • Enables to show the status of the books • Enables the clerk to customize the due time of returning books for photocopying purpose • Enables the user to search for a particular book using the system’s specialized built-in search engine • QR code scanner functionality Database data storage 3 Users and Characteristics There are essentially three users for the system and are expected to be computer-literate: the borrower, as this project is being made so obviously the main client for this system who wishes to borrow materials in the library. The students of the school are not only the borrower, faculty and other employees of Samar College who are in the list of the school’s employees, for confirmation, may borrow books if they give envelop to librarian, this envelop will serve as their record of borrowing. The borrower may also be a student from other schools, that are required to register (P 50. 0) to school’s registrar to access a privilege and utilize the offered 8 hours services; the librarian, the main user of the system who manages the library and its database and responsible for activities such as adding book records, deleting book records, updating book status such as if book is issued and etc. ; the clerk, the assistant librarian and secondary user of the system who has a privilege to lend books, they are expected to have a different privilege as to librarian. 4 OperatingEnvironmentXAMPP Link from proposed system Figure 2 – Operating environment

The system will be operated in the Samar College Library, as it was proposed to. When the user interacts into the system, the system will pass the user to the database, through XAMPP v. 3. 0. 12 which allows Windows program to transfer data to and from the database to record every interaction of the user. 5 Design and Implementation Constraints The current constraints on the project are related to the provision of hardware resources to implement and test high-performance features. At present, an Intel Dual-core processor is needed, with a 2 GB RAM, serves as the server, with XAMPP running on top of the Windows 7 operating system.

For better performance analysis, a number of dedicated workstations would be beneficial for the student workstation. The hardware that the project will be running on may constrain some design decisions pertaining to real-time and performance, as well as the scanner’s accuracy. Also, certain required hardware within the library imposes specific requirements on the project. The following is a list of constraints pertaining to the accuracy of the library system: • The information of all the users must be stored in a database that is accessible by the system. The students must have logged in upon entering the library before they can borrow materials or books. • The librarian only has the privilege andresponsibilityfor the system’s security and privacy. • Clerk and librarian have different privileges upon using the system. • LAN is not implemented. • BIOS of the system unit should be working to get the real-time in issuing of the books to the borrowers. 6 User Documentation The user can easily understand of the usage of the system with a user’s manual to be delivered with the system.

The manual would be helpful with the some screen shoots within it. User can easily learn operation of the system by displaying corresponding shortcuts on controls for simple task. Contacts numbers of the developers will be given to the school librarian for further assistance when complex problems arise. 7 Assumptions and Dependencies A number of factors that may affect the requirements specified in the SRS include: • The users have sufficient knowledge of computers. • The users know the English language, as the user interface will be provided in English. Hardware and system specifications might not compatible. • System might not supported by the operating system. • It is assumed that librarian and/or clerk might forget their password for logging in. Specific Requirements 1 External Interface Requirements Below is a list of enumerated requirements that provides additional specifications for the behaviour and functionality of the system. 1 User Interfaces Using this system is fairly simple and intuitive. A user, who has a familiarity with basic logging in navigation, should be able to understand all functionality provided by the system.

As Figure 3 shows, the user with different privileges can now select his workstation, with corresponding shortcuts for options, so that the system may give the user an access to these and may let the not be able to use those of privilege he usually should not have. [pic] Figure 3 – Main interface If the user selects the Open Librarian (Ctrl + L), system now then identify him as Librarian, a Server, and Figure 4 will display with a pop-up form that lets the Librarian to have a three (3) attempts of logging in. If the user failed to log in successfully, system then will automatically shuts down. pic] Figure 4 – Logging station for Librarian If the user selects the Open Clerk (Click + C), system now then identify him as Clerk and Figure 5 then will display asking for an IP address sin order to have a connection to Librarian Workstation, server. [pic] Figure 5 – Clerk station for connection As the Clerk workstation has successfully connected to its server, then Figure 6 now will be displayed. Letting the Clerk to log in, as same of Librarian, if the Clerk failed to log in successfully it will automatically shuts down. [pic] Figure 6 – Clerk station 2 Hardware Interfaces

Since the system will be installed in a Local Area Network (LAN) for collecting data from the users and also for updating the Library System and making reports, it is recommended by the developers, in order to have a maximum usage of the system, that the library should have the following: • at least one camera for students’ easy logging in and scanning of books; • printer for making reports; and • computer unit(s) for the Clerk Workstation(s). The librarian then has to decide the number of units whether the library’s clerks would use. 3 Software Interfaces

The system will use only one external software, XAMPP v. 3. 0. 12, for the connection between the system and database. The system has a built in QR (Quick Response) Code Reader. 4 Communications Interfaces The system will be installed and run in a LAN of computer units. 2 Functional Requirements This section provides the detailed list of all product operation with their corresponding specific use case. 1 Librarian Use Cases 1 Use case: Log in Diagram: Brief Description The Librarian accesses the system, and can do various tasks. Initial Step-By-Step Description

Before this use case can be initiated, the Librarian has already set up or prepared the units to be used. 1. The Librarian hits Ctrl + L, the option log in for a Librarian. 2. The system displays the pop-up login for the Librarian. 3. The Librarian selects the log in. 4. The system records the info into the database. 2 Use case: Log out Diagram: Brief Description The Librarian is signing off the system. Initial Step-By-Step Description Before this use case can be initiated, the Librarian has already successfully logged in. 1. The Librarian clicks his name at the left top of the form. . The system displays the pop-up confirmation for log out. 3. The Librarian selects the OK button. 4. The system records the info into the database. 5. The Librarian has logged out. 3 Use case: Search book Diagram: Brief Description The Librarian gets the list of books and info. Initial Step-By-Step Description Before this use case can be initiated, the Librarian has already successfully logged in. 1. The Librarian selects the form for books, borrowers, etc. then chose the book. 2. The system displays the list of books and shows the different categories. 3.

The Librarian selects the category. 4. The system gets the selected category to dataset and at the same time records it. 5. The system displays the matched book(s). 6. 4 Use case: Issue book Diagram: Brief Description The Librarian is able to issue the book(s) to the borrower(s). Initial Step-By-Step Description Before this use case can be initiated, the Librarian confirmed the borrower that he has a validated registration. 1. The system Librarian searches the books in the list. 2. The system displays the list of books and shows whether the book is listed and/or available. a.

If the book’s copy is more than one (1) and is available, the Librarian sets the due date/time. b. If the book is not available due to some reason, the system will automatically alerts the Librarian that the requested book(s) is not available and thus will automatically gives the reason(s). 3. The system gets the due date/time to be recorded to the database. 4. The system will give a confirmation that the transaction is successful. 5 Use case: Update database Diagram: Brief Description The Librarian wanted to do some tasks the he/she needed the data be manipulated in the database.

He or she also can update the database. Initial Step-By-Step Description Before this use case can be initiated, the system has verified that the Librarian is logged in. 1. The system displays categorized options of the entire data. 2. The Librarian selects the category. 3. The system gives other options of that selected category. 4. The system gets the selected category to dataset and at the same time records it. 5. The system displays the matched selected category. 2 Clerk Use Cases 1 Use case: Log in Diagram: Brief Description The Clerk accesses the system, and can do various tasks.

Initial Step-By-Step Description Before this use case can be initiated, the Clerk has already set up or prepared the units to be used. 1. The Librarian hits Ctrl + C, the option log in for a Clerk. 2. The system displays the pop-up login for the Clerk. 3. The Clerk selects the log in. 4. The system records the info into the database. 2 Use case: Log out Diagram: Brief Description The Clerk is signing off the system. Initial Step-By-Step Description Before this use case can be initiated, the Clerk has already successfully logged in. 1. The Clerk clicks his name at the left top of the form. . The system displays the pop-up confirmation for log out. 3. The Clerk selects the OK button. 4. The system records the info into the database. 5. The Clerk has logged out. 3 Use case: Search book Diagram: Brief Description The Clerk gets the list of books and info. Initial Step-By-Step Description Before this use case can be initiated, the Clerk has already successfully logged in. 1. The Clerk selects the form for books, borrowers, etc. then chose the book. 2. The system displays the list of books and shows the different categories. 3.

The Clerk selects the category. 4. The system gets the selected category to dataset and at the same time records it. 5. The system displays the matched book(s). 4 Use case: Issue book Diagram: Brief Description The Clerk is able to issue the book(s) to the borrower(s). Initial Step-By-Step Description Before this use case can be initiated, the Clerk confirmed the borrower that he has a validated registration. 1. The system Clerk searches the books in the list. 2. The system displays the list of books and shows whether the book is listed and/or available. . If the book’s copy is more than one (1) and is available, the Clerk sets the due date/time. b. If the book is not available due to some reason, the system will automatically alerts the Clerk that the requested book(s) is not available and thus will automatically gives the reason(s). 3. The system gets the due date/time to be recorded to the database. 4. The system will give a confirmation that the transaction is successful. 5 Use case: Return book Diagram: Brief Description The Clerk returns the book he/she has borrowed. Initial Step-By-Step Description

Before this use case can be initiated, the Clerk, now as borrower, must return the book on time. 1. The Clerk himself may return the book he has borrowed. 2. The Clerk selects the Borrowed tab on the Borrowed form. 3. The system will display on the grid the borrowed books including his book. 4. The Clerk may scan the book with QR Code, or he may manually put the accession number of the book. 5. The system them will check for its due date and time, evaluates the time consumed for penalty if the clerk wasn’t able to return the book on time. 6. The system records info into the database.

Note: All Librarian assistants in the school’s library are working students, so therefore they may somehow be a “ borrower”. 6 Use case: Add Diagram: Brief Description The Clerk adds some info, it might be adding books or borrowers to the database. Initial Step-By-Step Description Before this use case can be initiated, the Clerk has given permission from the Librarian and thus he has already data to be stored in the database. And he has successfully logged in to the Clerk’s form. 1. As he logged in, the clerk clicks the “ Add” tab on the Clerk’s workstation. 2.

The system displays an option on whether what the clerk wants to add or store. 3. The clerk chooses an option. 4. The system displays needed data to be filled out whether it’s either a new book or new borrower. 5. The system then evaluates the input before storing to the database. a. If the required data is completed, the system displays a message box as notification of a new data. b. If some required data is missing, otherwise, a message box will be displayed to notify that some important data are not properly filled out. 7 Use case: Update database Diagram: Brief Description

The Clerk modifies some data that are stored in the database. Initial Step-By-Step Description Before this use case can be initiated, the Clerk scanned some info, might in the book or borrower, and is incorrect. 1. The Clerk selects the “ Update” tab on the Clerk’s workstation. 2. The system displays the pop-up options of the data to be updated to be edited. 3. The system displays the info that the Clerk wanted to update. 4. After the Clerk verified the correct records, the system then will display the updated data of a specified record. 3 Borrower Use Cases 1 Use case: Log in

Diagram: Brief Description The Borrower, if student, logs in through the scanner by swapping their IDs with QR Code. Otherwise, if the scanner is not available he can manually input his student number. The faculty who wants to borrow has no record of logging in but they have to provide an envelope that the librarian refers to. Initial Step-By-Step Description Borrower enters the library. 1. The Borrower looks for the needed book(s) to borrow. He can ask the clerk to search the book(s) through the system. 2. The system displays the possible results for the input info. Use case: Borrow Diagram: Brief Description The Borrowers, either a student or faculty, borrows their needed book. Initial Step-By-Step Description Before the Borrower can have the needed book(s), he successfully logged in inside the library. 1. The Clerk selects the tab for borrowing within the Clerk’s workstation. 2. The system displays the required data to be filled out for the borrowing. 3. After the Clerk or Librarian hits the OK button, the system will evaluates the borrower if he or she has due book(s) that not yet been returned. 4.

The system displays the notification and due date and time of the borrowed book(s) upon the request of the Clerk for borrowing the book then records it to the database. 3 Use case: Return Diagram: Brief Description The Borrower returns the book he or she has borrowed. Initial Step-By-Step Description Before this use case can be initiated, the Clerk Borrower must log in inside the library. 1. The Borrower asks anyone among the Clerks for returning assistance. 2. The Clerk selects the “ Borrowed” tab from the Borrowed form. 3. The system will display on the grid all the borrowed books including his book. 4.

The Clerk may scan the book with QR code or he may manually input the accession number of the book. 5. The system them will check for its due date and time, evaluates the time consumed for penalty if the Borrower wasn’t able to return the book on time. 6. The system records info into the database. Other Non-functional Requirements 1 Performance Requirements 1. Response Time – The Splash Page should be able to be load within seconds using a Windows 7 32-bit Operating System and at least 1 GB memory (RAM). The information is refreshed every two minutes. The access time for the computer unit should be less than a minute.

The system shall respond to the member in not less than two seconds from the time of the request submittal. The system shall be allowed to take more time when doing large processing jobs. 2. Administrator/Librarian Response – The system shall take as less time as possible to provide service to the administrator or the librarian. 3. Throughput – The number of transactions is directly dependent on the number of users, the users may be the Librarian, employees of the Library and also the people who use the Library for checking-out books, returning books and checking library account. . Resource Utilization – The resources are modified according the user requirements and also according to the books requested by the users. 2 Safety and Security Requirements The server on which the Library System resides will have its own security to prevent unauthorized write/delete access. There is no restriction on read access. The use of email by an Author or Reviewer is on the client systems and thus is external to the system. The PC on which the Clerk resides will have its own security. Only the Editor will have physical access to the machine and the program on it.

There is no special protection built into this system other than to provide the editor with write access to the Library System to publish reports. 3 Software Quality Attributes 1 Functionality Logon Capabilities The system shall provide the users with logon capabilities. Alerts The system can alert the Librarian or the administrator with notifications regarding the status of the books and in case of any problem. 4 Usability • The system shall allow the users to access the system from a stand-alone client or its derivative technologies for public inquiries of the students.

The system uses another computer unit for the client interface. • The system is user friendly. 5 Reliability The system has to be very reliable due to the importance of data and the damages incorrect or incomplete data can do. Availability The system is available 100% for the user. The system shall be operational 8 hours a day and 7 days a week. Accuracy The accuracy of the system is limited by the accuracy of the speed at which the employees of the library and users of the library use the system. Access Reliability The system shall provide 100% access reliability. 10 Supportability

The system designers shall take in to considerations the following supportability and technical limitations. Information Security Requirement The system shall support the information security requirements. Maintenance The maintenance of the system shall be done as per the maintenance contract. Standards The coding standards and naming conventions will be as per the American standards. Appendix A – Data Dictionary | Borrower – Any person who wishes to borrow books inside the school library. | | Clerk – Any person who assists the librarian in minor tasks needed performed inside the library. | Database – A collection of all data produced by the system. | | Librarian – A person who is assigned responsible in generally managing the school library. | | QR Code – Quick Response code, a type of bar code/encrypted code that will be used for the project in identification purposes. | | Requirements – Refers to the “ what” the product has to do, not the “ how” it is be done. | | SC – Abbreviation of the name of the school where the system will be proposed, the Samar College | | SRS – Software Requirements Specifications.

A document that completely describes all of the functions of a proposed system and the | | constraints under which it must operate. For example, this document. | | Stakeholder – Any person with an interest to the project but is not a developer. | | User – Any person who operates or interacts directly with the product. | | VB – Visual Basic, a building/programming software used in creating the system | | XAMPP – An application used to have a connection between the product and its database. Appendix B – Group Log Notes Taken during our first meeting with Jun, Arnel & Marlon on January 23, 2013. •Interviewthe librarian • interview the library employees • understand the flow of data in the library • understand the processes used in transactions in the library • new design • lan network • create a floor plan including 3 units for 3 stations of the whole system • 3 stations: Admin station, Clerk Station, Log in Station • provides photocopies of authentic documents from the library • learn the penalty system of the library copy the list of books • list the basic requirements • Software Requirements Specification for Page 12 • fix the QR scanner • dry run the system • Should we try this for different operating system environment? • We might need licenses, ask if necessary. • Given our budgets, this is the best we can do. • Set up servers. • Began looking through test cases • Will work on SRS • Jun Abanag • Created QR code samples for ID • Will work on SRS. • Marlon Alegro. • Will work on SRS. • Jun Abanag. • Will work on SRS. • Scrum Meeting 2/8/2013 • Marlon Alegro Downloaded licensed software. • Worked on SRS. • Will work on feedback to finalize SRS. • Nicholas Cross • Worked on SRS. • Will work on feedback to finalize SRS. • Jun Abanag & Marlon Alegro • Worked on SRS. • Will wait on feedback from mentor to finalize SRS. Group activities • Overnight sessions (starts at 10 in the evening up to 5 in the morning: 7 hours) Most of us have part time jobs during day time and we have different schedules for Software Engineering so we used our time to work during evening and midnight because of the busy schedule during day time.

We spend seven hours during midnight to work on our system and the SRS. ? Alegro Residence one a week ? Abagua Residence one a week 11/15/2012 11/18/2012 11/19/2012 11/23/2012 12/4/2012 12/12/2012 12/15/2012 • Group meetings Since we have different schedules for Software Engineering, we try to meet up during free hours. And most of the times we are not complete because of the busy schedule. So what we do is two of our group mates meet up at certain time and the other one would discuss it to the other member when they meet.

So in that way we can exchange ideas even though we don’t meet properly. Afterwards, the other few members will also catch up with updates from the recent group discussion. ? Samar College, twice a week. Every Monday, Wednesday and Friday ? Alegro Residence one a week ? Abagua Residence one a week 11/15/2012 11/18/2012 11/19/2012 11/23/2012 12/4/2012 12/12/2012 12/15/2012 Index | A | Log out (use case), | | A –