srs introduction and library

8/9/2019 Srs Introduction and Library

1/22

Software Engineerring

Mini - Project

Software Requirement Specication

Submitted by :-

Shrukul Habib

13CO143

8904890754

[email protected]

Dharmendra Singh

13CO213 7795543419

[email protected]


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/software


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,


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


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


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


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/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:


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.


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.


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.


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.


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


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


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:


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


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


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

/


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

/


20/22

4.4 State Diagram

enter lo.inname

verif8 authenicate

issueboo,

chec, forboo,

returnboo,

caluculat

e fine

lo.ut


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,


22/22

4.7 Deployment Diagram

client pro.ram

web server

srs introduction and library

Documents