Software Engineerring

Mini - Project

Software Requirement Specification

Submitted by :Shrukul Habib
13CO143
8904890754
shrukul99@gmail.com
Dharmendra Singh
13CO213

7795543419
dharm0795@gmail.com

Software Requirement Specification [SRS]

Introduction
A software requirements specification (SRS) is a comprehensive description of the
intended purpose and environment for software under 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 an application will
interact with system hardware, other programs and human users in a wide variety of realworld 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
the IEEE (Institute of Electrical and Electronics Engineers) specification 830-1998.

Requirement tracing process :

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,

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 meetingsworkshops/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. It
also 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 nonfunctional requirements (e.g. specification of application availability level, time of data

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 Rules

Administrative functions

Authentication

Authorization levels

Audit Tracking

External Interfaces

Certification Requirements

Reporting Requirements

Historical Data

Legal or Regulatory 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

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?

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:

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
o
o
o
o
o
o
o

Correct
Unambiguous
Complete
Consistent
Ranked for importance and/or stability
Verifiable
Modifiable
Traceable

Correct - This is like motherhood and apple pie. Of course you want the specification to be
correct. 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.

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.

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.1 Purpose:
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 the
system 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.2 Scope:
The Software Requirements Specification captures all the requirements in a single document.
The Online Library 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 through
the 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.

 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.

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
search

admin

user

addMember

craeteRoles
return
member
issue
librarian
calculateFine
accountInfo

viewReport

Online users have four actors

1)
2)
3)
4)

2.2.

Administrator
User
Librarian
Member

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

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:

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

librarian

STUDENT

l_id
l_name
l-doj

S_name
S_id
S_department
borrow book()
return book()

1..*

issue book()
check id()
grant permission()
add book()

1..*

DATABASE
filename
update()
delete()

SUPPLIER
S-ID
S_NAME
SEARCH()
TELL AVAILABILITY()
OPNAME()

4.2 Sequence Diagram

user

Librarian

LMS

DataBase

1: authenicate user
2: succesful login
3: issue book
4: check for book status
5: available or waiting
6: suucessfully issued
7: return book
8: check status
9: calculate fine
10: return card

4.3Collaboration

Diagra

user
3: issue book
7: return book
6: suucessfully issued

2: succesful login

Librarian

LMS
8: check status

1: authenicate user
9: calculate fine

10: return card

5: available or waiting
4: check for book status

DataBas
e

4.4 State Diagram

verify

enter login
name

authenic
ate

check for
book

issue
book

logut

caluculat
e fine

return
book

4.5 Activity Diagram

authenic
ate
check for
book
available
issue
book
return
calculate
fine

late
in time

pay fine

return
card

logout

4.6 Component diagram

student

borrow book
librarian

4.7 Deployment Diagram

web server
client program