Lappeenranta University of Technology
Department of Information Technology
Laboratory of Information Processing
Requirements Specification
College Library Management System
Version 1.1 (final)
Requirements Engineer: Andrey Paklin 0242566
E-mail: paklin@lut.fi
Supervisor: Yana Selioukova
E-mail: Yana.Selioukova@lut.fi
Jan Voracek
E-mail: jan.voracek@lut.fi
Lappeenranta, Finland
2002
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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 ...........................................................................................................................................7
2. PROJECT CONSTRAINTS .......................................................................................................... 11
2.1 Mandated Constraints ........................................................................................................... 11
2.2 Implementation environment of the current system .................................................... 11
2.2.1 System Interface ..............................................................................................................................11
2.2.2 User Interface ...................................................................................................................................14
2.3
Partner applications ....................................................................................................... 15
2.4 Schedule ................................................................................................................................... 16
2.5 Budget ....................................................................................................................................... 16
3. FUNCTIONAL REQUIREMENTS ................................................................................................ 16
3.1 The Scope of the Work.......................................................................................................... 16
3.2 The Scope of the Product .................................................................................................... 17
3.3 Functional requirements ...................................................................................................... 18
4. NON - FUNCTIONAL REQUIREMENTS ................................................................................... 19
4.1 Look and Feel Requirements .............................................................................................. 19
4.2 Usability Requirements ........................................................................................................ 19
4.3 Performance Requirements................................................................................................. 19
4.4 Operational Requirements ................................................................................................... 19
4.5 Maintainability and Portability Requirements ................................................................ 20
4.6 Security Requirements ......................................................................................................... 20
4.7 Legal Requirements ............................................................................................................... 20
5. PROJECT ISSUES ....................................................................................................................... 20
5.1 Open Issues ............................................................................................................................. 20
5.2 User’s Documentation and Training ................................................................................. 20
5.3 Waiting Room .......................................................................................................................... 20
6. REFERENCES: .............................................................................................................................. 21
7. APPENDIX 1. SYSTEM MODELS .............................................................................................. 22
2
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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 (webbased) 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.
3
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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:
4
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
Table 1. End - Users
Stakeholder Identification
Knowledge needed by the
project
Necessary
degree
of
stakeholder’s involvement
Degree of influence for that
stakeholder
End - Users (librarians, patrons), College Library
Basic knowledge of Microsoft Windows-based interfaces, Internet
browser’s interfaces.
Low. End – Users are not involved in software development, just in
some kinds of sociological surveys
High. Software to be developed to satisfy first of all the End-Users.
Table 2. Customer
Stakeholder Identification
Knowledge needed by the
project
Necessary
degree
of
stakeholder’s involvement
Customer (National Innovation Foundation)
Customer’s requirements, Project plan, business modeling and
forecasting.
Middle. Customer supervises project, establishes budget
Degree of influence for that High. Software development process may be canceled by Customer.
stakeholder
Table 3. Project Manager
Stakeholder Identification
Project Manager (Fabian GARRIDO-MARTINEZ), The Dream Team
Corporation
Knowledge needed by the Project plan creating, computer skills.
project
Necessary
degree
of High. Project Manager supervises project, establishes team, provides
stakeholder’s involvement
deadlines, negotiates with customer.
Degree of influence for that High. All development process requires constant control and decision
stakeholder
making from Project Manager,
Table 4. Requirements Engineer
Stakeholder Identification
Requirements Engineer (Andrey Paklin), The Dream Team
Corporation
Knowledge needed by the SRS creating, computer skills.
project
Necessary
degree
of High. Requirements Engineer summarizes requirements provided by
stakeholder’s involvement
customer, updates them.
Degree of influence for that Middle. Requirements Engineer defines SRS under strict Customer
stakeholder
and Project Manager control
Stakeholder Identification
Table 5. System Designer
Vlasenko), The Dream Team
System Designer (Konstantin
Corporation
Knowledge needed by the Computer-based Design tools, Internet technologies
project
Necessary
degree
of High. System Designer defines all software interfaces, how the
stakeholder’s involvement
product will look like, providing success of product from the End –
5
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
Users point of view.
Degree of influence for that Low. System Designer will not use product to be developed in
stakeholder
appropriate way.
Table 6. System Tester
Stakeholder Identification
System Tester (Alex Kanavin), The Dream Team Corporation
Knowledge needed by the Computer-based
project
Necessary
Testing
tools,
Internet
technologies,
Testing
requirements and specifications.
degree
stakeholder’s involvement
of Middle. System Tester is looking for mistakes in software and verify
product’s possibilities.
Degree of influence for that Low. System Tester will not use product to be developed in
stakeholder
appropriate way.
Table 7. System Administrator
Stakeholder Identification
System Administrator, College staff
Knowledge needed by the Strong computer skills, Internet and network technologies.
project
Necessary
degree
stakeholder’s involvement
of Low. System Administrator is not involved in software development
process.
Degree of influence for that Middle. System Administrator will maintain and install product.
stakeholder
Table 8. Configuration Manager
Stakeholder Identification
Configuration
Manager
(Alex
Kanavin),
The
Dream
Team
Corporation
Knowledge needed by the Computer-based
project
Necessary
Testing
tools,
Internet
technologies,
Testing
requirements and specifications.
degree
stakeholder’s involvement
of High. Configuration Manager responsible for project repository,
project web pages.
Degree of influence for that Middle. Configuration Manager must follow job description and
stakeholder
deadlines, to prove his/her quality.
6
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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
User name
College Librarians
User role
To maintain College LMS (add, delete, renew items and update databases)
Subject matter
Master. College had the same management system in card-based form. All
experience
Technological
features of the old database are presented in new software product
Journeyman*, as less. Basic computer skills are obligatory.
experience
Intellectual
Middle intellectual abilities
abilities/disabilities
Age group
Adult age 25-65 (65 years old- is a pension age)
Table 9. Patrons
User name
User role
Library patrons
To use the College LMS in practice (from library or any place, where
Internet connection is available)
Subject matter
May ranges from novice to master.
experience
Technological
May ranges from novice to master, but basic computer skills and Internet
experience
working experience are obligatory.
Intellectual
May range in wide band
abilities/disabilities
Age group
16-65 (College students, professors, teachers, other staff)
*) - 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.
7
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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 10: Patrons viewpoint
Name
Patron
Focus
Searching, lending, requesting and renewing library items
Concerns
Source
Requirements
To familiarize patron with software functions
Requirements specification from the Customer

search for the books and other items

renew books and other items

browse catalogs

reserve unavailable items

subscribe for info about new acquisitions

access to other databases (interlibrary loans, online databases)
Table 11: Project manager viewpoint
Name
Project manager
Focus
Team establishment, project plan creating, control software development
process, follow schedule provided by the Customer
Concerns
Source
Requirements
College LMS creation according to deadlines
Job description

Follows deadlines and budget

Responsible for all deliverables

Easy communication with team and the Customer

All project stages should be fully documented

MS Word
8
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering

Internet connection

MS IE, Netscape or Opera browsers
08.03.2016
Table 12: Requirements engineer viewpoint
Name
Requirements engineer
Requirements specification creating, customer interviewing, collect and
Focus
Concerns
Source
specify requirements
Constantly updating SRS accordingly customer’s requirements
Requirements specification from the Customer

Requirements from patrons, Customer and team members should be
prepared
Requirements

Requirements should be clear, complete and consistent

MS Word

Internet connection

MS IE, Netscape or Opera browsers
Table 13: System Designer viewpoint
Name
System Designer
Focus
Design user interfaces, creation of design specification document
Concerns
Source
Requirements
Formal design
Project plan, requirements specification from the Customer

Clear and complete SRS

Adobe Photoshop

MS Word

Internet connection

MS IE, Netscape or Opera browsers
Table 14: System Tester viewpoint
Name
System Tester
Focus
Design testing strategies, creation testing documents, realize test cases
Concerns
Validation of software quality
9
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
Requirements specification from the Customer
Source
Requirements
ISO 9001 Standards

Knowledge of software to be tested

Testing tools

MS Word

Internet connection

MS IE, Netscape or Opera browsers
Table 15: System Administrator viewpoint
Name
System Administrator
Focus
Database installation, maintenance of College LMS
Concerns
Source
Requirements
College LMS maintenance and troubleshooting
Inner SRS from Requirement Engineer, Internet and LAN specifications

Licensed software with automatically update tools

MS Word;

Internet connection

MS IE, Netscape or Opera browsers
Table16: Configuration Manager viewpoint
Name
Configuration Manager
Focus
Configuration and change management, project repository control, project
web-pages maintenance and follow calendar of events
Concerns
Source
Change control to achieve Quality assurance required by the Customer
Inner company’s SRS
Job description
Requirements

All hardware and software should be available

Adobe Acrobat Reader

Internet connection

MS IE, Netscape or Opera browsers
10
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
2. Project Constraints
2.1 Mandated Constraints
Next items must be used to verify software:
1) For user home PC and library workstation
Hardware

IBM-compatible PC with Pentium processor and higher
 50Mbytes free space on HDD

32Mbytes RAM

Internet connection
Software

MS Windows 95/98/2000/NT/XP

MS IE, Netscape or Opera browsers with Java2 support
2) For Server
Hardware
 IBM-compatible PC with Pentium  and higher
 256Mbytes RAM or higher
 80Gbytes free space on HDD
Software
 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.
11
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
Database
SQL server
Library functions
database
Windows
Applications
Library system
engine (Java)
Library’s workplaces
User Interface
Engine (PHP)
Web
browser
Web
browser
Web
browser
Users’ personal computers
Figure 1
The LMS system, presented on Fig. 1, consists of four main blocks, each of them is
mandatory.
12
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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
distribution) and others.
Authorization
module
Search module
Library System
Engine
E-mail module
Figure 2
………………………
User Interface Engine (UIE). UIE allows to work with LMS system by means of Webbrowser (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
13
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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.
14
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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 userfriendly. 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
15
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering

LAN’s specifications

SMTP/POP e-mail protocols description
08.03.2016
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.
Deliverable
Project Plan
Requirements
documentation
Implementation
Plan
Project binder
Deadline
November 13, 2002
November 13, 2002
Time
10:00
10:00
Extended
NO
NO
November 27, 2002
12:00
YES
December 12, 2002
12:00
NO
Objective
Reached
Reached
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)
16
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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.
17
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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(webbased) 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
18
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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
19
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
 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.
20
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
6. References:
[1] Sommerville, Ian, Pete Sawyer, and Stephen Viller (1998), Viewpoints for requirements
elicitation: a practical approach, in Proceedings of the IEEE International Conference on
Requirements Engineering - ICRE'98, April 6-10, 1998, Colorado Springs, Colorado.
http://www.comp.lancs.ac.uk/computing/research/cseg/projects/reaims/publications.html
[cited 11.11.02]
[2] Volere Requirements Specification Template
http://www.volere.co.uk/template.rtf [cited 12.11.02]
[3] Software Requirements Specification (SRS) Template.
http://swiki.cc.gatech.edu:8888/uploads/cs4320/145/Srs.doc [cited 10.11.2002]
[4] Project-Based Software Engineering Homepage
http://www.it.lut.fi/kurssit/02-03/010752000/projects.html
[5] Pressman, R. S.: Software Engineering, A Practitioner's Approach (European adaptation,
fifth edition). McGraw Hill, 2000.
[6] IEEE Guide for Information Technology - System Definition - Concept of Operations
(ConOps) Document, IEEE Std 1362-1998
21
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
08.03.2016
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 1
Name
Login (Open program)
Actors
Patron or Librarian
Preconditions
Description
Existence of database and correctly installed web based server,
knowledge of standard Windows environment
Library user or Librarian opens program using browser, to logon to
system he/she must enter username and password.
End Result
Opened program, user see logon page.
Scenario 2
Name
Add, Remove, Modify item
Actors
Librarian
Existence of database and correctly installed web based server,
Preconditions
user logged on with librarian privileges.
Librarian using web interface adds, removes or modifies (e.g.
Description
End Result
quantity) information about item
Added, Removed or Modified information about item in database
22
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
Scenario 3
Name
Check for availability
Actors
Librarian, patrons
08.03.2016
Existence of database and correctly installed web based server,
Preconditions
user logged on with librarian privileges or patrons’ rights.
Through web interface librarian using item call number searches if
Description
this item is available
End Result
Returned status of item
Scenario 4
Name
Add, Remove, Modify user information
Actors
Librarian, System Administrator
Existence of database and correctly installed web based server,
Preconditions
user logged on with librarian privileges.
Using web interface forms for librarian or system administrator to
Description
add, remove or modify information about user
End Result
Added, Removed or Modified information about user in database
Scenario 5
Name
Generate overdue report
Actors
Librarian, the LMS
Existence of database and correctly installed web based server,
Preconditions
user logged on with librarian privileges.
Librarian defines overdue period for every category of item using
Description
End Result
web interface or installed college LMS
List of users and overdue items
23
The Dream Team Corporation, Requirements Specification v1.1
010752000 Team project, Project-Based Software Engineering
Scenario 6
Name
Search item
Actors
Patron or Librarian
08.03.2016
Existence of database and correctly installed web based server,
Preconditions
user logged on to system.
Patron or Librarian using web interface searches for item using
Description
author or item’s title.
End Result
List of found items are shown
Scenario 7
Name
View information
Actors
Patron
Existence of database and correctly installed web based server,
Preconditions
user logged on to system.
Paron using web interface view his/her status (User name,
Description
address, number of taken books, requested items)
End Result
User information are shown
Scenario 8
Name
Renew item
Actors
Patron
Existence of database and correctly installed web based server,
Preconditions
user logged on to system, at least one item taken.
User selects items he/she want to renew, using Renew button
Description
End Result
he/she renews selected items
Status are shown (renewed or not)
24