0% found this document useful (0 votes)
17 views18 pages

SRS On Libraray - Management - System

The document provides an overview of a software requirements specification for a library management system. It describes the purpose, scope, and definitions for the project. User classes and characteristics are defined. Design and implementation constraints are discussed, including the user interface technology, tools, and platforms to be used. Requirements such as functional, performance, security, and change management are outlined.

Uploaded by

Lê Quang Long
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views18 pages

SRS On Libraray - Management - System

The document provides an overview of a software requirements specification for a library management system. It describes the purpose, scope, and definitions for the project. User classes and characteristics are defined. Design and implementation constraints are discussed, including the user interface technology, tools, and platforms to be used. Requirements such as functional, performance, security, and change management are outlined.

Uploaded by

Lê Quang Long
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

Course Name: Documentation of software engineering

Course Code: SWE-131


Software Requirement Specification
On
Library Management System
Version:1.0
Submitted to:
Name: Shohel Arman Shuvo
Lecturer, Daffodil International University
Department: Software Engineering
Mirpur Road, Dhaka 1207, Bangladesh

Submitted by:
Name: Majharul Islam Towsif Sumon
ID: 171-35-1846
Department: SWE
Section: E
Mirpur Road, Dhaka 1207, Bangladesh
Date of Submission: 16-10-2018

SRS for LMS Page |i


Table of contents

Table of Contents i
List of Figures ii
1. Introduction 1
1.1 Purpose 1
1.2 Project Scope 1
1.3 Glossary …….1
1.4 References 2
1.5 Overview 2
2. User Classes and Characteristics 3
3. Design and Implementation Constraints 3
3.1 User Interface Technology 3
3.1.1 Programming Language 3
3.1.2 JavaScript and jQuery Library 3
3.1.3 CSS Framework 4
3.2 Implemented Tools and Platform 4
3.2.1 Web Server 4
1.1.1 Database Server 4
2. Use Case Diagram 5
3. Requirement Specification 5
3.1 Functional Requirements 6
3.2 Performance Requirements 7
3.2.1 Capacity Requirements 7
3.3 Dependability Requirements 8
3.3.1 Reliability and Availability 8
3.3.2 Robustness and Fault Tolerance Requirements 8
3.3.3 Safety Critical Requirements 8
3.4 Maintainability and Supportability 8
3.4.1 Maintenance Requirements 9
3.4.2 Supportability Requirements 9
3.4.3 Adaptability Requirements 9
3.5 Security Requirements 9
3.5.1 Access Requirements 10
3.5.2 Integrity Requirements 10
3.5.3 Privacy Requirements 10
3.5.4 Ease of Use Requirements 10
3.5.5 Understand-ability and Politeness Requirements 11
3.5.6 Accessibility Requirements 11
3.5.7 User Documentation 12
3.6 Operational and Environmental Requirements 12
3.6.1 Expected Physical Requirements 12
3.6.2 Requirement for Interfacing with Adjacent System 12
3.6.3 Release Requirements 13
3.7 Legal Requirements 13
3.7.1 Compliance Requirements 13
3.7.2 Standard Requirements 13
3.7.3 Release Requirements 13
3.8 Legal Requirements 13
3.8.1 Compliance Requirements 13
3.8.2 Standard Requirements 13
3.9 Requirement Elicitation Techniques 13
3.9.1 Hold Elicitation Interviews 13
3.9.2 Perform Document Analysis 13
3.9.3 Distribute Questionnaires 14
3.10 Requirement Validation 14
3.10.1 Review the Requirements 14
3.10.2 Test the Requirements 14
3.10.3 Simulate the requirements 14
3.11 Change Management 14

List of Figures

Figure 4.1 – Use Case Diagram for Library Management System 15


Figure 6.1 – State Diagram of Change Request……………………………………………15

Revision History
Name Date Reason For Changes Version

1. Introduction
The introduction of the Software Requirements Specification (SRS) provides an overview of
the entire SRS with purpose, scope, definitions, acronyms, abbreviations, references and
overview of the SRS. The aim of this document is to gather and analyze and give an in-depth
insight of the complete Library Management System by defining the problem statement in
detail. Nevertheless, it also concentrates on the capabilities required by stakeholders and their
needs while defining high-level product features. The detailed requirements of the Library
Management System are provided in this document.

1.1 Purpose

The purpose of the project is to maintain the details of books and library members of different libraries.
The main purpose of this project is to maintain a easy circulation system between clients and the
libraries, to issue books using single library card, also to search and reserve any book from different
available libraries and to maintain details about the user (fine, address, phone number) .Moreover, the
user can check all these features from their home

1.2 Project Scope

✔ Manually updating the library system into an android based application so that the user
can know the details of the books available and maximum limit on borrowing from their
computer and also through their phones.
✔ The ILM System provides information's like details of the books, insertion of new books,
deletion of lost books, limitation on issuing books, fine on keeping a book more than one
month from the issued date.
✔ Also user can provide feedback for adding some new books to the library.

1.3 Glossary

This subsection contains definitions of all the terms, acronyms, and abbreviations used in the
document. Terms and concepts from the application domain are defined.
● LMS –Library Management System
● SRS – System Requirement Specification
● SDLC – Software Development Life Cycle
● UI – User Interface

SRS for LMS Page |1


1.4 References

IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998.

1.5 Overview
The goal of this project is to provide simplicity as well as security and efficiency to the Management of
Agape Youth Library and also to reduce the management personal in the library.

Library Management System is a project which aims to develop a computerized system. The system
helps both students and the library manager to keep track of all books available in the library. It allows
both the admin and the student to search for the desired book.

The main feature of this system is that all books available in the library can be displayed in a list so that
students need not roam through the entire library to find a book. Additionally, the System effectively
maintains the users of the students / students whose books have been issued; It also records the issued
date and return date.

2. User Classes and Characteristics

There are three types of users in this system. The first two are, Admin, and Librarian, the only
distinction between them is that Admin are allowed to see the preference and exclusion sets
of other users. It is the third type of user, the administrator, who is able to initially setup the
system, add new users, and set their authorization level.

Users: Most members will be of the type users. They also can see all the Admin members’
associates to this system. They also can get the Admin card facilitates.

Librarian: The next most common type of user is the authorized Librarian. These users have
the same permissions as the general member’s with the additional ability to view other
member’s preference and exclusion set. They are allowed to post events notice even they also
can post job circular for general Librarian’s. Also they have the permission to change their
profile.

SRS for LMS Page |2


Admin: Finally, the system administrators are users who are able to setup the system from
the initial installation and maintain the systems member accounts. They automatically have
the functionality of authorized users within the normal operation of the system; however have
additional menu options which allow them to maintain the system.

3. Design and Implementation Constraints

Design and implementation constraints are those that we have used to implement this project
make successful. It also describes tool that enables developers and testers to view and interact
with the user interface (UI) elements of this application.

3.1 User Interface Technology

User interface (UI) is everything designed into a system view that which person’s associates
with this system may like the interface of this system.

3.1.1 Programming Language

For developing this system we will use PHP as a programming language. PHP (recursive
acronym for PHP: Hypertext Pre-processor) is a widely-used open source general-purpose
scripting language that is especially suited for web development and can be embedded into
HTML. PHP is a server scripting language, and a powerful tool for making dynamic and
interactive Web pages

3.1.2 JavaScript and jQuery Library

The most common use of JavaScript is to add client-side behaviour to HTML pages, also
known as Dynamic HTML (DHTML). Scripts are embedded in or included from HTML
pages and interact with the Document Object Model (DOM) of the page.
jQuery is a JavaScript library. jQuery greatly simplifies JavaScript programming. jQuery UI
is a curated set of user interface interactions, effects, widgets, and themes built on top of the
jQuery JavaScript Library. Whether you're building highly interactive web applications or
you just need to add a date picker to a form control, jQuery UI is the perfect choice. jQuery
UI is built for designers and developers alike. We've designed all of our plug-ins to get you up
and running quickly while being flexible enough to evolve with your needs.

SRS for LMS Page |3


3.1.3 CSS Framework

CSS is a language that describes the style of an HTML document. CSS describes how HTML
elements should be displayed. Build responsive, mobile-first projects on the web with the
world's most popular front-end component library.

Bootstrap is an open source toolkit for developing with HTML, CSS, and JS. Quickly
prototype your ideas or build your entire app with our Sass variables and mix INS, responsive
grid system, extensive prebuilt components, and powerful plug-ins built on jQuery.

The bootstrap code is included minified, which means that white spaces are removed to make
the file size smaller and therefore make the load time faster for the file which improves the
load time for the whole page. The main design that bootstraps ads without specifically adding
design to elements is that when hovering over a link. This is fixed with some simple CSS-
code added to the CSS-file, unless the bootstrap CSS-file is included after the original, then
bootstrap will override the custom ones and the changes will not be seen. Having some basic
knowledge about how Bootstrap works before starting to use it would increase the efficiency
and speed one might achieve the goal one has in mind for including bootstrap into the project.

3.2 Implemented Tools and Platform

Every business plan, campaign, or project comes down to Tactics, Tools, and Strategies. To
conceive, develop, and implement a sound social media marketing strategic plan that will be
successful needs to have those three critical components.

3.2.1 Web Server

A Web server is a program that uses HTTP (Hypertext Transfer Protocol) to serve the files
that form Web pages to users, in response to their requests, which are forwarded by their
computers' HTTP clients. Dedicated computers and appliances may be referred to as Web
servers as well. We will use the Apache HTTP server to implement this project

3.2.2 Database Server

We will use MySQL database server to store all of the information of this system. The reason
behind to choose the database server are given below:
● Security
● Reporting and Data Mining
● Replication
● Fault tolerance
● Performance diagnostics

SRS for LMS Page |4

Use case Diagram


1. Requirement Specification

The complete requirement specification based on the elicitation process is described in this
section.

The Functional Requirements Specification is designed to be read by a general audience.


Readers should understand the system, but no particular technical knowledge should be
required to understand the document.

SRS for LMS Page|5


FR-01 Member Information
Description This module helps admin to register alumni members. Admin is able to
maintain all the information of alumni members
Stakeholders Admin

FR-02 Update Members Details


Description This module helps admin to update alumni members’ information.
Admin and alumni members can update the details of the members and
we store these details in database.
Stakeholders Admin, Alumni member

FR-03 Unregistered Members


Description Admin can delete the details of the alumni member and it also deletes
these details in database.
Stakeholders Admin

FR-04 Search Member


Description Admin can search the details of the students and the system displays
the specific member
Stakeholders Admin

FR-05 View Member Details


Description Admin as well as members can view the entire details of the students
or members who are registered.
Stakeholders Admin , Alumni member

FR-06 Post Events and Notice


Description Admin as well as members can post or create any type events and
notice that is related to this alumni. All the members of this alumni can
see every events and notice
Stakeholders Admin , Alumni member
FR-07 Job Posting
Description The executive alumni members can post any job circular news to this
alumni system and the members of this system can comment on this
job posting and can share the post
Stakeholders Admin , Alumni member

FR-08 Messaging

SRS for LMS Page |6

Description All the registered alumni members can message to each other through
this system
Stakeholders Alumni members

FR-08 Messaging
Description All the registered alumni members can message to each other through
this system
Stakeholders Alumni members

3.2.1Performance Requirements

A requirement that specifies a performance characteristic that a system or system or system component
must possess; for example, speed, accuracy, frequency

5.2.1 Capacity Requirements

The system is able to manage all the information of passed out students.

PR-02 Initially the system will store 50,000 student information


Description The information of Alumni will be stored in database.
Stakeholders Admin, Librarian

5.3 Dependability Requirements

The flexibility of current frameworks encourage system architects to enable reconfiguration


mechanisms that refocus the available, safe resources to support the most critical services
rather than over-provisioning to build failure-proof system. Therefore, these requirements are
essentials.

5.3.1 Functional Requirements

The flexibility of current frameworks encourage system architects to enable reconfiguration


mechanisms that refocus the available, safe resources to support the most critical services
rather than over-provisioning to build failure-proof system. Therefore, these requirements are
essentials.

SRS for LMS Page |7


5.3.2 Reliability and Availability
In order to support global and smooth operations the system must be available around the
clock. On the other hand most services in this system are not mission-critical. Even better the
game posting can handle times of downtime as the users usually interact with high-
availability from third party website. This system will be able to catch up with their data once
it's up and running again.

DR-01 The system must be available 12x7


Description ● The system must be available 12 hours in a day
● The system must be updated regularly
● The system must publish the notice,

Stakeholders Admin, Librarian ,Users

5.3.3 Robustness and Fault Tolerance Requirements

The system will almost ensure 0% crush in any single minor error and don’t give any wrong
calculation.

DR-02 The system handles over access and system errors


Description Sometimes multiple users can over access to this system. The system
can handle multiple user access
Stakeholders N/A

5.3.4 Safety Critical Requirements

There are no specific safety critical requirements

5.4 Maintainability and Supportability

Supportability is the degree to which system design characteristics and planned logistics
resources meet system requirements. Supportability is the capability of a total system design
to support operations and readiness needs throughout the life-cycle of a system at an
affordable cost.

SRS for LMS Page |8


5.4.1 Maintenance Requirements

MS-01 The system helps to update any information in any time


Description The admin and Librarian can post any events and can enable to
change or update any information in any situation
Stakeholders Admin, Librarian,Users

5.4.2 Supportability Requirements

In order to understand the system's behaviour on a technical support required by the system
operator. The reason for reading them might be

● System malfunction has occurred and the system operator has to find the exact point
of time when this happened
● System produces wrong results and the developers must be able to reproduce the
data flow through the system
● Hacker tried to breach the system's security mechanisms and the system operator
must understand what he did

5.4.3 Adaptability Requirements

There are no specific adaptability requirements

5.5 Security Requirements

There are no access requirements beside those that have been outlined in the below:

● The software must validate all user input to ensure it does not exceed the size
specified for that type of input
● The server must authenticate every request accessing the restricted Web pages
● After authenticating the browser, the server must determine whether that browser is
authorized to access the requested restricted Web pages
● The system must have security controls to protect against denial-of-service attacks
● The system must encrypt sensitive data transmitted over the Internet between the
server and the browser
To get access to this system or a specific module the system must provide a central
authentication mechanism. In order to prevent anyone to exploit stolen all users password
must

SRS for LMS Page |9


5.5.1 Access Requirements

To get access to the system, the system provides authorization/authentication way. This
system uses various modules.

SR-01 The system provides security strategies.


Description The system is designed in way that allows all modules to access a
mechanism that provides security services.
Stakeholders Admin, Librarin , Users

5.5.2 Integrity Requirements

To protect credentials of user from being stolen, all passwords are stored in encrypted form.
The Requirements significantly reduces the value of stolen user credentials, it’s not easy to
decrypt the password.

5.5.3 Privacy Requirements

The system provides a protection of the database in the server. However, the system will have
to increment this level of protection because of the personal data mode available on the
system & the larger share of people that will be having access to it through the system’s
registration. The user’s privacy will be granted by the limited access that the log in process is
going to give to the database.

SR-02 All data will be protected


Description The main requirement in the context is the generation of Alumni
member’s data for analysis.
Stakeholders Admin, Librarin , Users
5.6 Usability and Human Integrity Requirements

These Requirements define how to meet the physical and cognitive needs of the intended
users of your website or application

5.6.1 Ease of Use Requirements

The system is easy to use and can easily be understandable.

SRS for LMS Page |10


UH-01 The system must be usable for Librarin , Users with all associate
stakeholders.
Description The system indicates the several possibilities that the Librarin , Users has
to go on in using the system. The alumni members are allowed to undo
any of the operation.
Stakeholders Admin, Librarin , Users

5.6.2 Understand-ability and Politeness Requirements

This section describes more requirements of DIU Alumni system to add more features in
future

UH-02 The features Library Management System


Description The system is more efficiently ease of use more added features .The
system is understand-ability for both user. The system will not use any
term that is not specified in this system.
Stakeholders Admin

5.6.1 Accessibility Requirements

We have 3 levels

User module: In the user module, user will check the availability of the books

⮚ Issue Book

⮚ Reserve book

⮚ Return book

⮚ Fine details

Library module

 Add new book


 Remove books

 Update details of book

SRS for LMS Page |11


Administration module:
The following are the sub module in the administration module :

 Register user

 Entry book details

 Book issue

To get access to this system or a specific module the system must provide a central
authentication mechanism. In order to prevent anyone to exploit stolen all users password
must be encrypted in hash process.

5.6.2 User Documentation

UH-03 The system developer documentation


Description To develop this project we have specified requirement of user
documentation. The teams are involved to this project documentation.
Stakeholders System Developer

5.8 Operational and Environmental Requirements

This Requirements focus on how the users will operate the system, including interfaces and
interoperability with other systems. The requirements establish how well and under what
conditions the system must perform.

5.8.1 Expected Physical Requirements

There are no specific expected physical requirements

5.8.2 Requirement for Interfacing with Adjacent System

There is no specific interfacing with adjacent system requirements


5.8.3 Release Requirements

There are no specific release requirements but in the project schedule section it was described
briefly.

SRS for LMS Page |12


5.9 Legal Requirements

These requirements consider any violence of rules and regulation and which rules should be
followed to maintain this system.

5.9.1 Compliance Requirements

There are no specific compliance requirements

5.9.2 Standard Requirements

There are no specific standard requirements

6 Requirement Engineering Process

Requirements engineering refers to the process of defining, documenting and maintaining


requirements in the engineering design process. It is a common role in systems engineering
and software engineering.

6.3 Requirement Elicitation Techniques

Requirement elicitation is the process of collecting and refining stakeholder’s requirements.


Projects are garbage-in-garbage-out meaning that poor quality requirements typically lead to
project issues and failure.

6.1.1 Hold Elicitation Interviews

We hold interviews that can be performed one-on-one or with a small group of stakeholders.
They are an effective way to elicit requirements without taking too much stakeholder time
because we meet with people to discuss only the specific requirements that are important to
this system. Interviews are helpful to separately elicit requirements from members in
preparation for workshops where those member of this system come together to resolve any
conflicts.

6.1.2 Perform Document Analysis


Existing documentation can help reveal how systems currently work or what they are
supposed to do. Documentation includes any written information about current systems,
business processes, requirements specifications, competitor research. Reviewing and
analyzing the documents can help identify functionality that needs to remain, functionality
that isn’t used.

SRS for LMS Page |13


6.1.3 Distribute Questionnaires

We conduct a survey to collect requirements for this system. Questionnaires are a way to
survey large groups of users to determine what they need. Questionnaires are useful with any
large user population but are particularly helpful with distributed groups.

6.2 Requirement Validation

Validation ensures that the requirements are correct and demonstrate the desired quality that
you want from this system. Requirements that seem fine when you read them might turn out
to have ambiguities and gaps when to try to work with them.

6.2.1 Review the Requirements

Peer review of requirements, particularly the type of rigorous review called inspection, is one
of the highest-value software quality practices available. Assemble a small team of reviewers
who represent different perspectives and carefully examine the written requirements, analysis
models, and related information for defects.

6.2.2 Test the Requirements

We tests constitute an alternative view of the requirements. We also conduct writing tests
about how to tell if the expected functionality was correctly implemented. Derive tests from
the user requirements to document the expected behaviour of the product under specified
conditions.

6.2.3 Simulate the requirements

To simulate the requirements commercial tools are available that we have used to simulate a
proposed system either in place of or to augment written requirements specifications.
Simulation takes prototyping to the next level.

6.3 Change Management


We used a common set of web-based tools for handling change requests and tracking open
issues is essential. Change always has a price, so using change management practices to
control scope creep is vital in a contract-development situation. We will provide these
following issues in change management.

SRS for LMS Page |14

● Evaluate and prioritize defect corrections and enhancement requests


● Dynamically adjust the scope of future releases or iterations
● Evaluate the impact of proposed changes on users and business processes
● Participate in making change decisions

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy