Upload
shrukul
View
250
Download
0
Embed Size (px)
Citation preview
8/9/2019 Srs Introduction and Library
1/22
Software Engineerring
Mini - Project
Software Requirement Specication
Submitted by :-
Shrukul Habib
13CO143
8904890754
Dharmendra Singh
13CO213 7795543419
8/9/2019 Srs Introduction and Library
2/22
Software Requirement Specification -
[SRS]
Introduction
A software requirements specification (SRS) is a comprehensive description of the
intended purpose and environment forsoftwareunder development. The SRS fully
describes what the software will do and how it will be expected to perform. It is usually
signed off at the end of requirements engineering phase.
SRS is basically an organizations understanding (in writing) of a customer or
potential clients system requirements and dependencies at a particular point in time
(usually) prior to any actual design or development work. Its a two-way insurance policy that
assures that both the clien and the organization understand the others requirements from
that perspective at a given point in time.
An SRS minimizes the time and effort required by developers to achieve desired
goals and also minimizes the development cost. A good SRS defines how anapplicationwill
interact with systemhardware,other programs and human users in a wide variety of real-
world situations. Parameters such as operating speed,response
time,availability,portability, maintainability,footprint, security and speed of recovery from
adverse events are evaluated. Methods of defining an SRS are described by
theIEEE(Institute of Electrical and Electronics Engineers) specification 830-1998.
Requirement tracing process :
http://searchsoa.techtarget.com/definition/softwarehttp://searchsoftwarequality.techtarget.com/definition/applicationhttp://searchcio-midmarket.techtarget.com/definition/hardwarehttp://searchcio-midmarket.techtarget.com/definition/hardwarehttp://searchcio-midmarket.techtarget.com/definition/hardwarehttp://searchnetworking.techtarget.com/definition/response-timehttp://searchnetworking.techtarget.com/definition/response-timehttp://searchnetworking.techtarget.com/definition/availabilityhttp://searchstorage.techtarget.com/definition/portabilityhttp://whatis.techtarget.com/definition/footprinthttp://whatis.techtarget.com/definition/IEEE-Institute-of-Electrical-and-Electronics-Engineershttp://searchsoftwarequality.techtarget.com/definition/applicationhttp://searchcio-midmarket.techtarget.com/definition/hardwarehttp://searchnetworking.techtarget.com/definition/response-timehttp://searchnetworking.techtarget.com/definition/response-timehttp://searchnetworking.techtarget.com/definition/availabilityhttp://searchstorage.techtarget.com/definition/portabilityhttp://whatis.techtarget.com/definition/footprinthttp://whatis.techtarget.com/definition/IEEE-Institute-of-Electrical-and-Electronics-Engineershttp://searchsoa.techtarget.com/definition/software8/9/2019 Srs Introduction and Library
3/22
The following diagram clearly depicts the process of SRS document development before
commencement of a project.
Process of requirements tracing begins with Business Requirements Specification. This is
the description of a company's business objectives, which are to be met using the
developed software. Such a document is drawn up from the perspective of business and
only contains general requirements, which are to be met by the new system. It is usually
created by the Client before project commencement.
If such need arises (in case of bigger projects), our analysts will prepare Vision Document
on the basis of BRS document. This is a concise document which initializes the project. It
has the following structure [based on the examples by Karl E. Wiegers]:
Business requirements
o project's business context,
o business objectives,
8/9/2019 Srs Introduction and Library
4/22
o project success criteria,
o user needs,
o business risks,
Solution vision
o general system description,
o list of its characteristics,
o assumptions and dependencies
Scope and limitation
o scope of functionalities in separate versions
o description of what the system will not contain
Business contest
o description of all stakeholders in the project
o description of project priorities
After acceptance of the document by all project participants, transition to phase of tracing
user requirements occurs. This is usually done by a series of meetings-
workshops/interviews, during which all subsequent system functionalities are analyzed,
which are ascribed to the business process.
During these workshops, analysts develop use cases or user histories. Such documents
describe in detail the process of user interaction with the application (and possible
interactions between systems). Sometimes user interface models (prototypes) are drawn up
as images of forms. Such image sometimes gives a better idea about system behavior. Italso allows for improvement of user interface ergonomic.
While designing user interfaces, we follow our usefulness principles and principles of
reasonable access to data, in orderto find the compromise between user requirements and
system load. Together with user requirements, other requirements are traced, including non-
functional requirements (e.g. specification of application availability level, time of data
8/9/2019 Srs Introduction and Library
5/22
storage in the database.) All requirements are collected together in the final Software
Requirements Specification document.
Types of Requirements:
The below diagram depicts the various types of requirements that are captured during SRS.
Functional :
Functional requirements describe the features, functioning, and usage of a
product/system/software from the perspective of the product and its user.
Some of the Functional Requirements are as follows :-
Business Rues
!"ministrati#e functions
!ut$entication
8/9/2019 Srs Introduction and Library
6/22
!ut$ori%ation e#es
!u"it &rac'ing
E(terna )nterfaces
Certication Requirements
Reporting Requirements
*istorica +ata
,ega or Reguator Requirements
Non-Functional
Non-functional requirements are not non-functional at all. Rather, they describe various
quality factors, or attributes, which affect the functionality's effectiveness. They do not
exist in the abstract but only with respect to relevant functionality.
Typically non-functional requirements fall into areas such as:
Accessibility
Capacity, current and forecast
Compliance
Documentation
Disaster recovery
Efficiency
Effectiveness
Extensibility
Fault tolerance
Interoperability
8/9/2019 Srs Introduction and Library
7/22
Maintainability
Privacy
Portability
Quality
Reliability
Resilience
Response time
Robustness
Scalability
Security
Stability
Supportability
Testability
Performance
Maintainability
Reliability
Interface
Safety
Quality
Operational
Resource
Benefits of a SRS?
8/9/2019 Srs Introduction and Library
8/22
The IEEE 830 standard defines the benefits of a good SRS:
Establish the basis for agreement between the customers and the suppliers on what the
software product is to do.The complete description of the functions to be performed by the
software specified in the SRS will assist the potential users to determine if the software
specified meets their needs or how the software must be modified to meet their needs.
Reduce the development effort.The preparation of the SRS forces the various concerned
groups in the customers organization to consider rigorously all of the requirements before
design begins and reduces later redesign, recoding, and retesting. Careful review of the
requirements in the SRS can reveal omissions, misunderstandings, and inconsistencies
early in the development cycle when these problems are easier to correct.
Provide a basis for estimating costs and schedules.The description of the product to be
developed as given in the SRS is a realistic basis for estimating project costs and can be
used to obtain approval for bids or price estimates.
Provide a baseline for validation and verification.Organizations can develop their validation
and Verification plans much more productively from a good SRS. As a part of the
development contract, the SRS provides a baseline against which compliance can be
measured.
Facilitate transfer .The SRS makes it easier to transfer the software product to new users or
new machines. Customers thus find it easier to transfer the software to other parts of their
organization, and suppliers find it easier to transfer it to new customers.
Serve as a basis for enhancement.Because the SRS discusses the product but not the
project that developed it, the SRS serves as a basis for later enhancement of the finished
product. The SRS may need to be altered, but it does provide a foundation for continued
production evaluation. [NOTE: This is often a major pitfall when the SRS is not continually
updated with changes]
What should the SRS address?
From the IEEE standard:
8/9/2019 Srs Introduction and Library
9/22
The basic issues that the SRS writer(s) shall address are the following:
a)Functionality.What is the software supposed to do?
b)External interfaces.How does the software interact with people, the systems
hardware, other hardware, and other software?
c)Performance.What is the speed, availability, response time, recovery time of
various software functions, etc.?
d)Attributes.What are the portability, correctness, maintainability, security, etc.
considerations?
e)Design constraints imposed on an implementation.Are there any required
standards in effect, implementation language, policies for database integrity,
resource limits, operating environment(s) etc.?
Characteristics of a SRS
An SRS should be :-
o Correct
o Unambiguous
o Complete
o Consistent
o Ranked for importance and/or stability
o Verifiable
o Modifiable
o Traceable
Correct- This is like motherhood and apple pie. Of course you want the specification to becorrect. No one writes a specification that they know is incorrect. We like to say - "Correct
and Ever Correcting." The discipline is keeping the specification up to date when you find
things that are not correct.
8/9/2019 Srs Introduction and Library
10/22
Unambiguous -An SRS is unambiguous if, and only if, every requirement stated therein
has only one interpretation. Again, easier said than done. Spending time on this area prior
to releasing the SRS can be a waste of time. But as you find ambiguities - fix them.
Complete -A simple judge of this is that is should be all that is needed by the software
designers to create the software.
Consistent -The SRS should be consistent within itself and consistent to its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in
another.
Ranked for Importance -Very often a new system has requirements that are really
marketing wish lists. Some may not be achievable. It is useful provide this information in the
SRS.
Verifiable -Don't put in requirements like - "It should provide the user a fast response."
Another of my favorites is - "The system should never crash." Instead, provide a quantitative
requirement like: "Every key stroke should provide a user response within 100 milliseconds."
Modifiable -Having the same requirement in more than one place may not be wrong - but
tends to make the document not maintainable.
Traceable -Often, this is not important in a non-politicized environment. However, in most
organizations, it is sometimes useful to connect the requirements in the SRS to a higher
level document. Why do we need this requirement
A Simple Case Study On SRS :
1. Introduction:
Borrowing books, returning books or viewing the available books at the Library of the local
University is currently done manually where in the student has to go to the Library and check the
available books at the Library. Students check the list of books available and borrow the books if
the book is a borrow book otherwise it is of waste for the student to come to the library to come
to check for the books if the student doesnt get the book. Then the librarian checks the student
id and allows the member to check out the book and the librarian then updates the member
database and also the books database.
8/9/2019 Srs Introduction and Library
11/22
This system would be used by members who may be students or professors of that University to
check the availability of the books and borrow the books, and by the librarian to update the
databases. The purpose of this document is to analyze and elaborate on the high-level needs
and features of the Online Library System.It focuses on the capabilities and facilities provided
by a Library. The details of what all are the needs of the Online Library System and if it fulfils
these needs are detailed in the use-case and supplementary specifications.
1.1Purpose:
The purpose of Software Requirements Specification (SRS)document is to describe the
external behavior of the Online Library System. Requirements Specification defines and
describes the operations, interfaces, performance, and quality assurance requirements of the
Online Library System. The document also describes the nonfunctional requirements such as
the user interfaces. It also describes the design constraints that are to be considered when thesystem is to be designed, and other factors necessary to provide a complete and
comprehensive description of the requirements for the software. The Software Requirements
Specification (SRS) captures the complete software requirements for the system, or a portion of
the system.
1.2Scope:
The Software Requirements Specification captures all the requirements in a single document.
The OnlineLibrary System that is to be developed provides the members of the Library and
employees of the library with books information, online blocking of books and many other
facilities. The Online Library System is supposed to have the following features.
The product provides the members with online blocking of books capabilities and the
Online Library System is up and running all day.
The system provides logon facility to the users.
The system provides the members with the option to check their account and/or change
their options like password of the account whenever needed all through the day during
the library hours.
The system allows the members to block the books 24 hours a day and all the throughthe semester.
The system lets the library staff to check which all members have blocked the books and
whether they can borrow any more books or not.
The system allows the Librarian to create the books catalog, add/delete books and
maintain the books catalog.
8/9/2019 Srs Introduction and Library
12/22
The system updates the billing system as and when the member borrows or returns a
book.
The book catalog is automated and the decision of offering the book based on the
category of the book is automatically decided.
We also have an order department, which manages to add or remove a book from the
Library.
1.3. Glosaary
Term Definition
Librarian Person who is the administrator of the
system. He is the main actor of the
system.
User Person who utilizes the services of a
Online Library.
Database Collection of all the information
monitored by the system.
Software Requirements Specification A document that completely describes
all of the functions of a specific system.
1.4 Overview:
SRS will include two Major sections:
1)Overall Description:This section of the SRS will provide the general factors that affect
the product and its requirements. It provides the background for those requirements. The
items such as product perspective, product function, user characteristics, constraints,
assumptions and dependencies and requirements subsets are described in this section.
8/9/2019 Srs Introduction and Library
13/22
2)Requirement Specification:This section of SRS contains all the software requirements
mentioned in section 2 in detail sufficient enough to enable designers to design the
system to satisfy the requirements and testers to test if the system satisfies those
requirements.
2)Overall Description:
2.1 System Environment:
addItem
addMember
craeteRoles
adminuser
search
member
issue
viewReport
accountInfo
return
calculateFine
librarian
8/9/2019 Srs Introduction and Library
14/22
Online users have four actors
1)Administrator
2)User3)Librarian
4)Member
2.2. Functional Requirements Specification
This section outlines the use cases for each of the actors separately.
2.2.1. Librarian
Use case: issue books, account info, calculate fine, view report.
The role performed by librarian is
1) Librarian issues the book to the students
2) Later while the student returns the book, he checks the account of the student
3) Based on the last return date, he calculates the fine
4) Later he return the card, updates the database and views the report
2.2.2 Administrator
Use case:addItem, addMember, createRoles, search for user.
The role performed by Administrator is
1)He can add members to the library i.e user
2)he can create new roles in the library to manage the library
3)he also can search for user to make further verification
4)he can add new item to the library database
8/9/2019 Srs Introduction and Library
15/22
2.2.3 User
Use case:search
1)he can search for the book and get the book issued
2)later he returns the book based on the return date
2.2.4 Member
Use case:return, search
1)a member can search for the book
2)later he returns the book based on the return data
2.3. User Characteristics
A librarian can add, delete and update book status and search from the database. A user can
borrow, return books, reserve books and search for books. He can also renew his loan period. If
a book is overdue, the user will be fined $0.10 each day over the due. If a book is reported lost,
the user will pay the full cost of the book.
The library is a nation-wide library with several branches. When the users searches the books,
the system will output which branches have the books, and which branch is the nearest to user's
home address. The search function allows both users and librarians to search by title, rating,
category, author, publisher, ISBN, language, branch, keywords. The system also allows
browsing by the same parameters.
There is a feedback system where the users can give a rating and comments to the book
after they have returned it
3. Non Functional Requirements
3.1 Security Features:
8/9/2019 Srs Introduction and Library
16/22
Only the authorized members can access the database. This is done by giving a separate id to
everyone accessing the database.
3.1.1 Constraints:
1) The person whose name is on the id is responsible for all the books taken on it.
2) When the book is returned to the library, make sure that the database is updated.
3) Keep the id in secret, in order to avoid others misusing it.
4) If the books is not returned in time , the students will be fined.
5) When the last date is crossed, the fine database will automatically be updated.
3.1.2 Safety Requirements
The database may get crashed at any certain time due to virus or operating system failure.
Therefore, it is required to take the database backup.
4. DIAGRAMS FOR LIBRARY MANAGEMENT
4.1 Class Diagram
8/9/2019 Srs Introduction and Library
17/22
SUPPLIER
S-ID
S_!ME
SE!R"#$%&ELL !(!IL!)ILI&*$%
+P!ME$%
S&UDE&
S_name
S_id
S_department
borrow boo,$%
return boo,$%
D!&!)!SE
filename
update$%
delete$%
librarian
l_id
l_namel-do
issue boo,$%
chec, id$%
.rant permission$%
add boo,$%
/001 /
/001
4.2 Sequence Diagram
8/9/2019 Srs Introduction and Library
18/22
userLMS
Librarian Data)ase
/2 authenicate user
32 succesful lo.in
42 issue boo,
52 chec, for boo, status
62 available or waitin.
72 suucessfull8 issued
92 return boo,
:2 chec, status
;2 calculate fine
/
8/9/2019 Srs Introduction and Library
19/22
4.3Collaboration Diagra
Data)ase
user
LMS Librarian
/2 authenicate user
32 succesful lo.in
42 issue boo,
52 chec, for boo, status
62 available or waitin.
72 suucessfull8 issued
92 return boo,
:2 chec, status
;2 calculate fine
/
8/9/2019 Srs Introduction and Library
20/22
4.4 State Diagram
enter lo.inname
verif8 authenicate
issueboo,
chec, forboo,
returnboo,
caluculat
e fine
lo.ut
8/9/2019 Srs Introduction and Library
21/22
4.5 Activity Diagram
authenicate
chec, forboo,
issueboo,
return
returncard
calculatefine
lo.out
available
late
in time pa8 fine
4.6 Component diagram
student
librarian
borrow boo,
8/9/2019 Srs Introduction and Library
22/22
4.7 Deployment Diagram
client pro.ram
web server