图书管理系统需求说明书英文版

Requirements Specification College Library Management System

Version 1.1 (final)

Table of Contents

1. PROJECT DRIVERS ....................................................................................................................... 3 1.1 Purpose . ...................................................................................................................................... 3 1.2 Scope . .......................................................................................................................................... 3 1.3 Abbreviations ............................................................................................................................ 4 1.4 Client, Customer and other Stakeholders ...................................................................... 4 1.5 Users of the Product................................................................................................................ 7 1.5.1 The Users of the Product . .................................................................................................................7 1.5.2 Viewpoints . ..........................................................................................................................................8 2. PROJECT CONSTRAINTS .......................................................................................................... 13 2.1 Mandated Constraints . .......................................................................................................... 13 2.2 Implementation environment of the current system .................................................... 13 2.2.1 System Interface ..............................................................................................................................14 2.2.2 User Interface ...................................................................................................................................16 2.3 Partner applications ....................................................................................................... 18 2.4 Schedule ................................................................................................................................... 18 2.5 Budget ....................................................................................................................................... 19 3. FUNCTIONAL REQUIREMENTS . ............................................................................................... 19 3.1 The Scope of the Work.......................................................................................................... 19 3.2 The Scope of the Product .................................................................................................... 20 3.3 Functional requirements ...................................................................................................... 21 4. NON - FUNCTIONAL REQUIREMENTS ................................................................................... 22 4.1 Look and Feel Requirements .............................................................................................. 22 4.2 Usability Requirements ........................................................................................................ 22 4.3 Performance Requirements . ................................................................................................ 23 4.4 Operational Requirements . .................................................................................................. 23 4.5 Maintainability and Portability Requirements ................................................................ 23 4.6 Security Requirements ......................................................................................................... 24 4.7 Legal Requirements . .............................................................................................................. 24 5. PROJECT ISSUES ..................................................................................................................... 24 5.1 Open Issues ............................................................................................................................. 24 5.2 User’s Documentation and Training ................................................................................. 24 5.3 Waiting Room .......................................................................................................................... 24 6. REFERENCES: .............................................................................................. 错误！未定义书签。 7. APPENDIX 1. SYSTEM MODELS .............................................................................................. 25

1. Project Drivers

1.1 Purpose

The purpose of this document is to familiarize reader with software, which is developed by Dream Team Corporation. Specification describes all hardware and software requirements for product, behavior of it and its components. Software Requirements Specification (SRS) allows to verify the customer that all his requirements are observed and implemented correctly by developer.

The intended audience for the SRS reading consists of system end-users (patrons), customer engineers, software developers (defined by Ian Sommerville for system requirements)[1].

1.2 Scope

The Dream Team Corporation was invited to develop College Library Management System for National Innovation Foundation (N.I.F). The software will reflect all the requirements defined by the customer.

College Library Management System will allow to perform all necessary procedures for librarians and patrons. According to customer requirements the software to be developed will consist of three databases:

✓ Item‟s database (books, journals, magazines, newspapers, diploma thesis, etc) ✓ Patron‟s database

✓ a small Access-based database with information about digital items, that College has (software, music) integrated with Item‟s database

LMS will also provide all necessary services for databases such as creating, deleting, updating and searching information. Patrons will be able to access to the library site (web-based) through the Internet or through the library‟s LAN -connected computers,

scattered throughout the library for sending request, receiving information about current status of the books or renewing them. The design of product interface to be developed will be supported by Microsoft IE, Netscape Navigator and Opera browsers. User interfaces will be ergonomical and easy-to-use.

1.3 Abbreviations

∙ LMS – Library management system ∙ SRS – Software requirements specification ∙ PC – Personal Computer ∙ HDD - Hard Disc Drive ∙ RAM – Random Access Memory

∙ LUT – Lappeenranta University of Technology ∙ IE – Microsoft Internet Explorer

1.4 Client, Customer and other Stakeholders

1.4.1 The client is the person/s who pay for the development, and owner of the delivered system.

National Innovation Foundation became the Dream Team Corporation‟s client in this project. The N.I.F will receive the final acceptance of the system, and thus must be satisfied with the developed system or not.

All client remarks will be improved immediately. Product deliverables have appropriated project schedule, approved by the client.

1.4.2 The customer is the person/s who will buy the product from the client. In our case, the roles of the client and the customer are filled by the same company.

1.4.3 Stakeholders include:

End - Users (detailed in section 1.5)

✓ Customer ✓ Project Manager ✓ Requirements Engineer ✓ System Designer ✓ System Tester ✓ System Administrator ✓ Configuration Manager

SRS identifies each type of stakeholder:

Table 1. End - Users

Table 2. Customer

Table 3. Project Manager

Table 4. Requirements Engineer

Table 5. System Designer

Table 6. System Tester

Table 7. System Administrator

Table 8. Configuration Manager

1.5 Users of the Product

1.5.1 The Users of the Product

Potential Users of the College LMS are librarians and patrons.

Table 8. Librarians

Table 9. Patrons

*) - journeyman, some kind of human experience degree, it’s situated between novice and master

1.5.2 Viewpoints

This project consists of several stakeholders, which were defined above. According to Ian Sommerville‟s article „Viewpoints for requirements elicitation: a practical approach‟ [2] software requirements can be described by using PREview model. The viewpoint model is deliberately flexible and informal. Viewpoints can be adapted to specific organizational practice and standards as can the notations used to describe system requirements. Viewpoints may be used during the early stages of a requirements engineering process as a structuring mechanism for requirements elicitation and analysis. Identifying viewpoints and organizing information around them at this stage reduces the possibility that critical information will be missed during requirements elicitation and provides a traceability mechanism for linking requirements with their sources. Let us define the following model of stating a viewpoint PREview: The viewpoint name . The viewpoint focus . The viewpoint concerns . The viewpoint sources . The viewpoint requirements .

Table 13: System Designer viewpoint

2. Project Constraints

2.1 Mandated Constraints

Next items must be used to verify software: 1) For user home PC and library workstation IBM-compatible PC with PentiumI processor and higher 50Mbytes free space on HDD 32Mbytes RAM Internet connection MS Windows 95/98/2000/NT/XP

MS IE, Netscape or Opera browsers with Java2 support 2) For Server IBM-compatible PC with Pentium III and higher 256Mbytes RAM or higher 80Gbytes free space on HDD MS SQL server and MS Access (Database server) MS Internet Information Server (Web server) Java Development Kit 1.2 and higher

Development environment – Java2 programming language

2.2 Implementation environment of the current system

2.2.1 System Interface

In order to achieve proper system performance following system interface (Figure 1)

was developed by our company.

The LMS system, presented on Fig. 1, consists of four main blocks, each of them is mandatory.

Database. Database is intended for storing different types of data such as users, books etc.

SQL server. This server is intended for Database management. It receives commands from Library System Engine and according its demanding take data from database.

Library System Engine (LSE). This is the core of LMS system. It is intended for processing of client‟s inquires and has standard library of functions. By means of this functions LSE connects to database server (SQL server) and generate requests for data issue, data renew, deleting data, etc from database. Requests are made on standard language named Structured Query Language (SQL). LSE can be implemented by different ways. In this LMS system it will be implemented in Java.

As it‟s shown at Fig. 2, LSE consist of several modules (every module response for certain operation): authorization module, search module, e-mail module (intended for e-mail

User Interface Engine (UIE). UIE allows to work with LMS system by means of Web-browser (through the web). It can be implemented in PHP script language for connection between server database and user web interface. UIE interacts with LSE by means of byte stream protocol. This protocol allows to provide interaction between programs realizing user interface (Web or Windows) and core of LMS. Byte stream protocol consist from set of messages of certain types such as request for registration, registration‟s result, request for search, result of search and others.

2.2.2 User Interface

The LMS is designed for using by two main classes of users: librarians and patrons. If according to log data user have “user” status then after logon he/she will see main window showed on the Figure 3.

Main user‟s menu consists:

∙ Users Info: here user can find his personal data (fig.5); ∙ Account: information about loans (fig.6);

∙ Search: provide detailed search through the library (fig. 7); ∙ Password: this function intended for changing user‟s password; ∙ Home: return user to main window (fig.4);

∙ Log Out: this function is intended for exit from user‟s settings.

Fig. 3 User Interface

As for librarians, they have similar interface, but some control features are added. If according to log data user have “user” status then after logon he/she will see main window showed on the figure 4.

Fig. 4 Main librarian‟s page

Main librarian‟s menu consists:

∙ Users Info: here user can find his personal data ; ∙ Account: information about loans;

∙ Subscribers: provide detailed information about all users; ∙ Items: provide detailed information about all library‟s resources; ∙ Password: this function intended for changing user‟s password; ∙ Home: return user to main window;

∙ Log Out: this function intended for exit from user‟s settings.

All user interfaces was developed to ease LMS using, they are ergonomical and user-friendly. Also all interfaces follow customer requirements.

2.3 Partner applications

There are some applications that are not part of the product but with which the product will collaborate. This section can be completed, by including written descriptions, models or references to other specifications.

ISO/OSI model TCP/IP specifications L AN‟s specifications

SMTP/POP e-mail protocols description

The physical work environment constrains the way that work is done. The product should overcome whatever difficulties exist, however you might consider a redesign of the workplace as an alternative to having the product compensate for it.

2.4 Schedule

The Schedule is presented by the Project Manager, strictly followed by the Dream Team Corporation and is proved by the Customer. The project was started at the beginning of the October.

2.5 Budget

Budget is not completely assigned to the Project.

3. FUNCTIONAL REQUIREMENTS

3.1 The Scope of the Work

At the beginning of October 2002 the Dream Team Corporation was represented a task to develop a College Library Management System by National Innovation Foundation (N.I.F). Software to be developed should be provide all necessary action for library staff and patrons. There are several motivations to order new computer-based College LMS:

1. To modernize College Library database, where data was stored in a card-based catalog

2. To optimize librarians‟ work and time

3. To join small Access-based database, where library has stored information about digital items (software, music)

4. To expand services of library and patron‟s possibilities

5. To check ability of commercial using of library management systems.

The LMS will allow remote access to library database via Internet only for patrons after authorization procedures. The patrons could search, renew items, send requests. The College LMS will provide remote access to other databases (interlibrary loans, online databases).

3.2 The Scope of the Product

Features provided by the library management system:

1. Store necessary information about items in the library:

- Author; - Item‟s title; - Call number; - Published place; - Year of publication - Location in the library; - Number of copies - Current status - Keywords

2. Allow a search item by author, title or keywords

3. System will provide librarian to add, modify, and remove items to/from the library database, and check availability of the item.

4. System will allow patron to get information about his/her status after authorization procedures: - User name - User address

- Student number

- Number and information about checked out items

- Requested items information

5. Notification by e-mail automatically after item‟s overdue.

6. Possibility to search, renew and order items though the Internet after authorization

procedures.

7. Possibility to search and request items in the interlibrary loans, online databases

through Internet.

3.3 Functional requirements

Functional requirements are the following:

1. The LMS should store all information about librarians and patrons, their access

keys, priority and etc.

2. The LMS should store all information about items and patrons in two separated

databases

3. The LMS allow searching items by author, title or keywords

4. The LMS should support 500 patrons and 1000 requests/min simultaneously.

5. The LMS should allow librarians to add, delete and modify items in database, and

check availability of the items.

6. The LMS should generate request‟s reports for librarians every day, on base of

which librarians could make decisions about acquiring or retirement the item

7. The LMS should create notification and send to patrons by e-mail automatically

after item‟s overdue

8. The LMS should allow patrons to get their personal information and status.

9. The LMS should provide to search, request and renew items either from the library

computers (LMS application) or from outside the library through College

site(web-based) though the Internet.

10. The LMS should provide access to previous Access-based database, online

databases

11. The LMS will be integrated with other colleges and universities and allow

interlibrary loans

4. Non - Functional Requirements

4.1 Look and Feel Requirements

According to the Customer requirements, the College LMS should include following

interfaces:

The LMS interfaces will the same for patrons and librarians based on C++/Java

application. Differences will depend on users‟ functions. Patrons will have simple

version of LMS without add, remove and modify possibilities.

The LMS interface for system administrator will include C++/Java application,

Command Line, System files

Web interface. This interface will provide search, request and renew procedures,

connection with other online databases. Web interface should work correctly in

different browsers.

4.2 Usability Requirements

As it was mentioned above, product‟s users are an adults, that‟s why there are no

special requirements to simplicity of system.

Ergonomical and clear interface

The interface should contain prompts and help to avoid making mistakes

The product should be used by people with no training

4.3 Performance Requirements

Any interface between a user and LMS should have a maximum response time of 5

seconds

The response should be fast enough to avoid users‟ response collisions

The LMS should be available for use 24 hours per day, 365 days per year.

The LMS should support 500 patrons and 1000 requests/min simultaneously

4.4 Operational Requirements

The LMS should be used on IBM-compatible workstations with 50Mbytes free

space on HDD for library workstations (80Gbytes for server) and 32Mbytes RAM for

library workstations (256Mbytes for server)

The LMS should be correctly implemented in different Internet browsers

The LMS should correctly interface if MS Access applications and MS SQL Server

4.5 Maintainability and Portability Requirements

Changes (new patrons addition, password changes, database changes) must be

verified once per day at least

The LMS should provide automatically notification to patrons by e-mail about item‟s

overdue, reservation results, availability of reserved item and etc

The LMS is expected to run under MS Windows 95/98/2000/NT/XP

4.6 Security Requirements

The LMS should provide databases‟ modification only for librarians and system

administrator after authorization procedures

Access to the LMS is permitted only for College student and staff after authorization

procedures

4.7 Legal Requirements

Personal information should be protected

The LMS should comply with quality assurance standards

5. Project Issues

5.1 Open Issues

Requirements elicitation haven‟t yet completed, thus SRS are constantly updated by

Requirements Engineer.

5.2 User’s Documentation and Training

User documentation is under construction now and will be available accordingly to

schedule. System Designer will present guide of User‟s Interfaces.

5.3 Waiting Room

Requirements that will not be part of the agreed product. These requirements might be included in future versions of the product.

7. Appendix 1. System Models

Scenarios

The following stages describe main scenarios performed by the LMS:

- Login to the system;

- Add, Remove, Modify item;

- Check item for availability;

- Add, Remove, Modify user information;

- Overdue report generating;

- Search item;

- View information;

- Renew book.

Scenario 2

Scenario 3

Scenario 4

Scenario 5

Scenario 6

Scenario 7

Scenario 8