Library management system Software Requirements Specification For Islamic University

Software Requirements Specification

1. Introduction

1.1 Purpose

The purpose of this document is to fully describe the software requirements for the library management system for Islamic university. These requirements were created in response to a request for proposals from Islamic university and have been developed through further elicitation, negotiations, and feedback.

The intended audience of this document includes the prospective developers of the software and the personnel at Islamic university who are assisting in assessing the completeness and accuracy of the requirements.

1.2 Scope

The LM system will integrate and improve upon the existing systems used by Islamic university in the following ways:

· By providing access to detailed library records and automatic tracking of a borrower position in the library;

· By providing an in depth library equipment interface with electronic sign out request and automatic location tracking capabilities; and

· By maintaining supply stock information within the system to ensure that stock does not run out.

· Update library with latest books and new material.

A web interface will also be provided for visitors and books to access from their home computers and on-site kiosks that will serve general library information.

The goal of the system is to more easily facilitate all administrative activities and information management tasks at the library, decrease the loss of expensive books, and reduce visitor line-ups at information desks.

1.3 Definitions, Acronyms and Abbreviations

Database A database is a collection of information stored on a computer in a systematic way, such that a computer program can consult it to answer questions. The software used to manage and query a database is known as a database management system (DBMS). MySQL, PostgreSQL, Oracle and Microsoft SQL are a few of the common DBMS.

EMS The EMS (Electronic Medical Summary) is based on the Cumulative Books Profile (CPP) as advocated by the College of Physicians and Surgeons under its Committee on Office Medical Peer Assessment (COMPA). The CPP contains a summary of key medical information such as medications, allergies, a problem list and a past medical history etc. The BCMA proposes that EMS be the electronic equivalent of the Cumulative Books profile.

Healthcare Personnel The term healthcare personnel applies to all medical staff who works in St. Peter library, such as doctors and nurses.

HTTP HTTP (or HyperText Transfer Protocol) is a set of rules whose primary method used to transfer information (text, images, sound, video, and other data files) on the World Wide Web.

Internet The Internet is the publicly available worldwide system of interconnected computer networks that transmit data packets by using a standardized Internet Protocol (IP) and many other protocols.

Intranet An intranet is a local area network (LAN) used internally in a company to facilitate communication and access to information that is sometimes access-restricted.

Network Congestion A term used to describe a bottleneck of data packets sent over a network much like a traffic jam with cars. Some of the data trying to be sent will timeout and will be attempted again in the future.

Real-Time An operation within a larger dynamic system is called a real-time operation if the time it takes to complete a task is shorter than the maximum delay that is allowed.

LM The acronym for this project: Supplies, Equipment, and Books Tracking. This project will be known as the “SEPT system” or the “system” from herein.

Stock A supply accumulated for future use.

TCP/IP The Internet protocol suite is the set of communications protocols that implement the protocol stack on which the Internet runs. It is sometimes called the TCP/IP protocol suite, after the two most important protocols in it: the Transmission Control Protocol (TCP) and the Internet Protocol (IP).

Tracking Device A small device that is attached to an object. A tracking sensor will detect when a tracking device is close to it.

Tracing Sensor An electronic device that detects when a tracking device is near by and transmits the information to a tracking interface node.

Tracking Interface Node A computer attached to many tracking sensors that compiles the information it receives.

XML Extensible Markup Language is general purpose markup language that is often used to transfer data over networks. XHTML for website design is an example of another markup language based on XML.

1.4 References

IEEE Std 830-1998. IEEE Recommended Practice for Software Requirements Specifications. Available online at http://segal.cs.uvic.ca/seng321/lectures/IEEE_Standard_1998.pdf.

Islamic UniversityLibrary
January 21, 2005. Available online at http://www.defnad.com/seng321group2client/St_Peters_SEPT_RFPv1.doc.

Wikipedia contributors. Wikipedia, The Free Encyclopedia. Available online at http://en.wikipedia.org/.

1.5 Overview

The remainder of this document contains: an overall description of the LM system in section 2, specific requirements, rational and test cases in section 3, followed by an exploration of the system architecture in section 4.

2. Overall Description

2.1 Product Perspective

Islamic University Library requires the development of a system that completely integrates and extends the functionality of their current systems for book search, borrow and return tracking system. The library requires the books tracking system that can meet their capacity of larger number of students simultaneously and a book borrower tracking system that can monitor in excess of 1000 pieces of expensive equipment. Furthermore, the supply database will be required to hold information on stock of a 5000 square foot supply warehouse.

Throughout the library’s has large buildings, tracking sensors will be placed in doorways to pickup signals from the tracking devices attached to books. The SEPT system will be available through the library by a network made of the library’s existing staff computers. An additional interface will be developed for visitors and books accessible at kiosks stationed throughout the library or on the internet from the library webpage. The figure below illustrates the connection of main components of the system.

Figure 2.1-1: Block diagram of the system components

The LM staff interface will provide all authorized library staff with the ability to access book database, user information and other information as well as the tracking features of the system. The web/kiosk interface will provide visitors and user with library information. The tracking hardware interface relays signals from the sensing equipment to the software system. Tracking system will check and ensure incoming and out going library user whether they are keeping some books or not. All tracking data are served from the database server which is accessed over the library’s Intranet and externally to the website via the Internet.

2.2 Product Functions

The LM system has the following features:

· Book record can be access

· A books current location in the library may be tracked

· New books may be signed out and tracked

· User information can be maintained

· books availability status may be maintained

· Library and books visitation information shall be publicly available through the Internet

· Access permission groups may be managed

· Security personnel may monitor in real time

2.3 User Characteristics

There are five main groups of users who will use the system, each with their unique requirements and varying technical skills levels.

2.3.1 Administrative personnel

Administrative personnel require that all library operations, from mundane to system-critical, run efficiently and without problem. Administrative personnel will have extensive management experience and a detailed working knowledge of most the librarys operations.

2.3.2 Healthcare personnel

The doctors and nurses require immediate access to books information and medical equipment. Healthcare personnel have had experience with data entry and computer applications as used in the old system, or at other libraries or elsewhere.

2.3.3 Security personnel

Security requires that all medical equipment and books are in their correct locations and that restricted areas are not breached. The security personnel have extensive experience monitoring outputs of systems and responding to alerts.

2.3.4 Member user

The supply staff requires that data entry of supply stock be as efficient and accurate as possible. They also have had extensive experience with data entry with mainly Microsoft Access.

2.3.5 Visitors

Visitors require access to general books information (room number and visiting hours) from the Internet and on-site kiosks. The technical skill level and physical capabilities of the visitors and books will vary greatly from extremely limited to very high.

2.4 Constraints

As per Islamic University Library’s request, the development of this system must be constrained in the following ways:

1. The implementation of this system must not disrupt the library’s operation during the transition from the current systems.

2. The system must be maintained by at most three IT technicians.

3. Training must be provided by Tri-Systems to familiarize the library’s employees with the system before it goes online (employees are not available for training more than two days per month).

4. Islamic University Library reserves the right to terminate the project at no extra expense if the project fails to meet its proposed deadline.

5. Due to limited funding for this project, the library will not be able to pay more than 25% above the estimated project cost.

2.5 Assumptions and Dependencies

In order for the LM system to function, the following assumptions and dependencies apply:

2.5.1 The current Oracle DBMS will be available for use by the new system

In accordance with the Islamic University Library request (in their RFP) the system must operate using their current version of Oracle DBMS. This existing Oracle DBMS will be used as one of the three Oracle DBMS systems required to run the new system as per the specs in this document (see 3.3.1 for additional information on triple redundancy.)

2.5.2 User computers are available and networked to the library’s Intranet

The system is dependent on all staff computers being connected to the library’s Intranet for secure access to the database server.

2.5.3 Security cards have been issued and readers are located at computers where needed

For secured user login the system requires that the staff have been issued keycards and that their computers are equipped with a card reader if needed.

2.5.4 Approval has been granted to access the provincial EMS system

This is required for interfacing with the systems own medical history database.

3. Specific Requirements

3.1 Functionality

3.1.1 F1 Books records may be accessed

As requested in Islamic university this program should store books record in database.

3.1.1.1 RS1 By default, the system shall store Books information

R1 From the Islamic university and negotiations, the system will store the following information by default. The following is defined as the default because additional fields may be added as

· Identifying information (Book Name)

· Book detail

· Author name

· Author detail

· Number of copy

· Category and use of book

· Number of reader and last access

· Reserved condition

TS1 Test Scenario: Information about a test book is stored on the system. The system is queried with the identifying information for the test book. When successful, the correct book information associated with the identifying information in the database is displayed on the screen.

3.1.1.2 RS2 Book information fields can be added, removed or re-labeled

R2 As requested during negotiations, administrators can add, remove or re-label the fields that store the information that is editable by library authorized staff.

The following details respond to the concern about error responses noted in the feedback to RS 2.0: Any changes (addition, modification and removal of fields) will require the user to confirm the change. In the event that an error occurs the change will not be made and the user will be notified.

TS2 Test Scenario: the system is used to add, delete and modify a test books information field. The system is queried with a test books. When successful, the system displays the test book with the added field. The system does not display the deleted field. The system displays the new field name.

3.1.1.3 RS3Book information fields shall be read-only, read/write, or read/add

R3 As requested during negotiations, books information fields can be protected by assigning different levels of access to them. These access levels include read only, read/write, or read/add only. Read only refers to the ability to view what has already be entered into that field, but not modify its contents. Read/write gives full access to that field to view what is already there and make changes to it. Read/add refers to the ability to read and add an additional item to the field, but not remove any information that was already there. (More detail added as requested in feedback to RS 2.0.)

TS3 Test Scenario: Permissions are assigned to three fields. Field 1 is read only. Field 2 is read/write. Field 3 is writing only. A test books is added to the system. The system is queried for the test books. Then fields 1,2 and 3 are modified. When successful, the system is queried and displays field 1 and field 2. When the system is modified, it displays an error when field 1 is modified.

3.1.1.4 RS4The system shall allow new books to be added

R4 This is essential for the continued use of the system. Name and healthcare number are required for creating new books. Medical history and contact information will be retrieved from the provincial EMS.

TS4 Test Scenario: A new books is added to the system. The system is queried with the new books identifying information. When successful, the system displays the correct information about the new books.

3.1.1.5 RS5 The system shall log changes made to books information

R5 As requested during negotiations, tracking changes to all medical information provides a way of tracing incorrect changes to the person who made them. During further discussion it was decided that the following information will be logged:

· The user who made the change

· What was changed (including the previous value)

· When the change was made

It was also requested during the negotiations that there be some way to notify the user viewing the record that a particular field has a change log (such as a flag beside the field that link to the change history). The change logs shall not be modifiable by anyone.

TS5 Test Scenario: A test books is stored on the system. Its information is modified. A query is made to the system for the test books information. Another query is made to the log for the books information. When successful, the modifications to the information are successful. The log is successfully updated and the results to the log query show the correct information.

3.1.1.6 RS6 The system shall obtain medical records from the British Columbia medical record system

R6 As requested during negotiations, the provincial EMS information shall be available as part of a books’s medical record that is maintained in the system. Whenever a books’s information is requested, the system shall query the provincial medical record system for additional data.

The following clarification was requested in the feedback to RS 2.0. The request is placed on a queue and is handled as soon as possible (in most cases this will be immediately after being queued), but in the event that the provincial medical record system is down, the query will remain in the queue until it can be processed. Once the query has been completed it will update the records inside the SEPT system (if appropriate) with the new information. The user will be notified that the system cannot communicate with the provincial medical record system at this time and that the information will be updated as soon as possible.

TS6 Test Scenario: Authorized medical staff may access the books information tab within the books tracking interface. This books document will automatically synchronize with provincial medical records. On successful retrieval and synchronization a success message will appear.

3.1.1.7 RS7 The system shall update provincial medical records to the provincial medical record system

R7 As requested during negotiations, books information maintained in the system shall be able to update provincial EMS data with new medical information and history. When a books’s information is updated in the system, the new data is added to a queue that will be sent to the provincial database when possible.

The following clarification was requested in feedback to RS 2.0. As mentioned above, any updates requiring to be published to the provincial medical records system is added to a queue. The entries in the queue are published to the provincial medical record system as soon as possible (in most cases immediately upon being added to the queue), but in the event that the provincial medical record system is unavailable the updates will remain in the queue until they can be published. The system will present the user with a visual notification cautioning them that their changes may not appear in the provincial medical record system immediately because SEPT is having difficulties communicating with the system at this moment. This notification will also reassure the user that all changes have been recorded by SEPT.

TS7 Test Scenario: Authorized medical staff may access the books information tab within the books tracking interface. After the user makes their desired changes they may click the submit button for the system to send the current copy to the provincial medical records. Upon success, there will be a message displaying "Update Successful". Otherwise there may be a failure message if an error occurred during the update.

3.1.2 F2 The system will track the current locations of books in the library.

As requested in the RFP, this is required so books may be quickly located for immediate treatment and monitoring entry to restricted areas.

3.1.2.1 RS8 Books location shall be displayed as the current building, wing, floor and room that they are in

R8 As requested in the feedback to RS 2.0, books’s location will consist of the building name, wing, floor number and room number that they are presently in.

TS8 Test Scenario: Authorized medical staff will use the books tracking interface on login and enter search criteria for the specific books they seek. Upon a successful search they can click the resulting books within the search result list and their location on a map is displayed on the right panel.

3.1.2.2 RS9 A books current location shall be updated automatically and in real-time

R9 As stated in the RFP, knowledge of the books location is only valuable if it is up-to-date and automatically updated by the system. This further detail was requested in the feedback to RS 2.0: a books location is only updated when the books moves through a door equipped with tracking sensors. If books are not presently moving the system will have the up-to-date location of the books in the system already. Subject to the performance requirement 3.4.1.

TS9 Test Scenario: Once the tracking information of a books is selected and displayed, when the books passes sensors the system will automatically update the database accordingly and update the display of the user interface reflecting their current location last detected by the tracking sensors.

3.1.2.3 RS10 Books shall be identified by searching by information or location

R10 As requested during negotiations, in order to find particular books, a user may search any of the books information fields for matching criteria. A user may also search by requesting which books are in a specified location. Locations may be a particular room or floor in the library.

TS10 Test Scenario: Once the tracking interface is accessed, a search interface is available allowing for books information or location to be searched. On success a list fitting the criteria will be displayed on the list of search results. If a location is searched for, such as a room, then all books within that room will be displayed in the results.

3.1.3 F3 Medical equipment shall be recorded, tracked, and signed out

As requested in the RFP, the tracking of equipment shall be automated and signing out shall be digitized.

3.1.3.1 RS11 The following information shall be stored by the system

R11 As requested in the RFP, the system will store the following information about medical equipment:

· Staff member who signed out item

· Sign out time

· Sign in time

· Duration item was signed out

· Intended destination of item

· Current location of item

This requirement is based on Use Case 2: Finding and Editing Information for Equipment (4.3.2).

3.1.3.2 RS12 Equipment shall be signed-out whenever it is in use

R12 As requested during negotiations, library staff will sign-out a piece of equipment through the system when it is being taken into an area where it will be used. Equipment that is in use has an intended destination, which is input by the user when it is signed-out. Equipment that is not signed-out is expected to be in a storage room, ready to be signed-out when needed. This requirement came from Use Case 3: Signing out equipment (4.3.3).

3.1.4 F4 The system shall store and monitor stock information

As requested in the RFP, the supply staff is responsible for storing and monitoring supply levels to ensure that stock never runs out by alerting the appropriate staff of low supplies.

3.1.4.1 RS13 The following supply information shall be stored by the system:

R13 As requested in the RFP, the system will store the following information:

· Product information

· Stock in warehouse

· Minimum supply level (used to trigger low supply notifications)

The minimal supply level will accept an integer value to represent a suitable quantity for the supply it is associated with. When the quantity of a supply drops below the minimum supply level associated with it, a notification will be generated. (Requested in feedback to RS 2.0.)

This requirement arose from Use Case 7: Creating an In-House Supply Order (4.3.7).

3.1.4.2 RS14 The system will notify the administrative personnel and supply staff when stock is low

R14 As requested in the RFP, low supply alerts will notify staff to re-stock supplies in order to prevent potential problems during emergencies.

This clarification was requested in response to RS 2.0. When the quantity of a supply drops below the minimum level it will generate a low stock notification that is added to a queue. This notification will be displayed to all administrators and supply staff when they are logged into the system until the supply level is restocked.

3.1.4.3 RS15 Supply inventory history shall be stored for 1.5 years

R15 As requested during negotiations, supply inventory history will be maintained and cannot be deleted for a minimum of 1.5 years from the date of entry. After 1.5 years has passed the data shall be available for removal by the system administrator.

3.1.5 F5 The system shall storeroom and bed availability status

As requested in the RFP, this will allow fast allocation of rooms to books in need.

3.1.5.1 RS16 The status of beds and rooms is associated with the books occupying it

R16 When a books has an assigned to a room and bed, the room and bed availability is automatically updated. (Requested in the RFP and updated in response to the feedback to RS 2.0.) This allows for the most accurate count of beds and rooms in use or available. Beds have the following statuses: available, occupied, requires maintenance and requires cleaning. Rooms have the following statuses: empty, partially filled and full.

3.1.5.2 RS17 Information maintained on bed availability is to consist of which building, wing, floor number and current status

R17 As requested in the feedback to RS 2.0, the information that is to be maintained about bed availability will consist of bed number, which building, wing and floor is it located on, as well as whether it is currently occupied.

3.1.6 F6 Library and books visitation information shall be publicly available

As requested in the RFP, this will be provided through the library’s website and on-site visitor information kiosks. This feature came from Use Case 4: Using the Kiosk/Website (4.3.4).

3.1.6.1 RS18 The system shall allow users to access general information about the library

R18 Requested in the RFP. To enable users to gain a better understanding of Islamic University Library including, contact information, history and services offered.

3.1.6.2 RS19 Website and visitor information kiosks shall provide floor plans of library

R19 Requested in the RFP. To help users locate rooms and specific departments in the librarys, reduce the number of questions asked to staff which decreases their work load and allowing them to be more productive in other areas.

3.1.6.3 RS20 The system shall provide visitors with the library's visiting hours

R20 This informs potential visitors of library visiting hours so they visit at the allowed times preventing the occurrence of confused and frustrated visitors.

3.1.6.4 RS21 Website shall allow users to obtain a map of the library's location

R21 This is to aid visitors and books to plan their commute to the library.

3.1.6.5 RS22 Website and visitor information kiosks shall display books's room numbers

R22 As requested in the RFP, and clarified during requirements elicitation, books’s room numbers will be available on the web and through visitor information kiosks. This allows visitors to find the location of the books easily. Books consent is required to allow the library to comply with privacy laws and giving books the choice to allow their name to be listed if they expect many visitors.

3.1.6.6 RS23 The website shall present specific, plain language error message to the user in the event of a failed transaction

R23 This is to avoid any confusion of the user and to protect sensitive data being dumped to the screen from a default error message (functionality added from feedback to RS2.0).

3.1.7 F7 Users and groups may be created and access permissions shall be modified

3.1.7.1 RS24 Administration staff shall be able to create new users and groups

R24 As requested during negotiations, members of the administration user group will have the ability to create new users and groups, as well as modify the permissions of the groups. Requirement extracted from Uses Case 5: Creating users, user groups, and setting permissions (4.3.5).

3.1.7.2 RS25 The system shall restore previous group permission if a fatal error occurs during a transaction

R25 This will prevent erroneous permission settings to be stored in the system by reverting to the previous settings and displaying a message to the user (clarification requested in feedback to RS2.0).

3.1.7.3 RS26 The system shall provide default user groups

R26 The default user groups, as initially requested in the RFP, shall be:

· Administrative personnel

o Access to all system functionality (no restrictions shall be placed upon this group)

· Healthcare personnel

o Access to books tracking and records

o Access to equipment tracking and sign-out

· Security personnel

o Access to books tracking

o Access to equipment tracking

· Supply staff

o Access to supply stock maintenance

· Visitors

o Access to website and visitor information kiosks

3.1.7.4 RS27 Group access to system functionality shall be restricted by the group’s permission settings

R27 As requested during negotiations, permissions settings shall control the user group’s access to the system functionality (tracking, signing out equipment), as well as their ability to change the information in the system.

3.1.8 F8 Security personnel may monitor books and equipment in real time

3.1.8.1 RS28 The system shall alert security personnel if restricted areas of the library are accessed by unauthorized books

R28 As requested in the RFP, security staff shall receive notification when restricted areas are breached.

Additional detail requested during feedback to RS 2.0 follows. Notifications are added to a queue and displayed to all security personnel currently logged in to the system. It will remain in the queue until it is manually removed by security staff. If no security personnel are logged into the system at the time of the alert th