The document outlines a Software Requirement Specification (SRS) for a library management system, detailing user registration, book management, and usability, efficiency, performance, and reliability requirements. It also discusses risks in software project development, including cost, performance, and schedule risks, explaining how these can affect project outcomes and techniques for managing them, such as Work Breakdown Structure (WBS) and the Program Evaluation Review Technique (PERT). Additionally, it highlights the need for accurate estimations and risk analysis to ensure project success.

1. “Software engineering’’
Assignment submitted to:-
Mr. mahendra Tiwari sir
Submitted By:
Rajat Mittal
Roll Number :- 13
Enrollment Number :- 16AU/665
In partial fulfillment of the requirements
for the award of the degree
of
Bachelor of Technology

2. Question:- 1. Write the SRS for library management.
Answer:-
Software Requirement Specification(SRS) can be broadly
classified as-
1. Register:-
▪ Description : First the user will have to register/sign up. There are
two different type of users.
▪ The library manager/head : The manager have to provide details
about the name of library ,address, phone number, email id.
▪ Regular person/student : The user have to provide details about
his/her name of address, phone number, email id.
1.1: Sign up
▪ Input: Detail about the user as mentioned in the description.
▪ Output: Confirmation of registration status and a membership
number and password will be generated and mailed to the user.
▪ Processing: All details will be checked and if any error are found
then an error message is displayed else a membership number and
password will be generated.
1.2 : Login
▪ Input: Enter the membership number and password provided.
▪ Output : User will be able to use the features of software.
2. Manage books by user.
2.1 : Books issued.
▪ Description : List of books will be displaced along with data of
return.

3. 2.2 : Search
▪ Input : Enter the name of author's name of the books to be issued.
▪ Output : List of books related to the keyword.
2.3 : Issues book
▪ State : Searched the book user wants to issues.
▪ Input : click the book user wants.
▪ Output : conformation for book issue and apology for failure in
issue.
▪ Processing : if selected book is available then book will be issued
else error will be displayed.
2.4 : Renew book
▪ State : Book is issued and is about to reach the date of return.
▪ Input : Select the book to be renewed.
▪ Output : conformation message.
▪ Processing : If the issued book is already reserved by another user
then error message will be send and if not then conformation message
will be displayed.
2.5 : Return
▪ Input ; Return the book to the library.
▪ Output : The issued list will be updated and the returned book will be
listed out.
2.6 ; Reserve book
▪ Input ; Enter the details of the book.
▪ Output : Book successfully reserved.
▪ Description : If a book is issued by someone then the user can
reserve it ,so that later the user can issue it.
2.6 Fine
▪ Input : check for the fines.

4. ▪ Output : Details about fines on different books issued by the user.
▪ Processing : The fine will be calculated, if it crossed the date of
return and the user did not renewed if then fine will be applied by Rs 10
per day.
3. Manage book by librarian
3.1 Update details of books
3.1.1 Add books
▪ Input : Enter the details of the books such as names ,author ,edition,
quantity.
▪ Output : confirmation of addition.
3.1.2 Remove books
▪ Input : Enter the name of the book and quantity of books.
▪ Output : Update the list of the books available
➢ Usability Requirement
The system shall allow the users to access the system from the phone
using android application. The system uses a android application as an
interface. Since all users are familiar with the general usage of mobile
app, no special training is required. The system is user friendly which
makes the system easy.
➢ Availability Requirement
The system is available 100% for the user and is used 24 hrs a day and
365 days a year. The system shall be operational 24 hours a day and 7
days a week.

5. ➢ Efficiency Requirement
Mean Time to Repair (MTTR) - Even if the system fails, the system will
be recovered back up within an hour or less.
➢ Accuracy
The system should accurately provide real time information taking into
consideration various concurrency issues. The system shall provide
100% access reliability.
➢ Performance Requirement
The information is refreshed depending upon whether some updates
have occurred or not in the application. The system shall respond to the
member in not less than two seconds from the time of the request
submittal. The system shall be allowed to take more time when doing
large processing jobs. Responses to view information shall take no
longer than 5 seconds to appear on the screen.
➢ Reliability Requirement
The system has to be 100% reliable due to the importance of data and
the damages that can be caused by incorrect or incomplete data. The
system will run 7 days a week, 24 hours a day.

6. This part of the specification will provide enough information about the
environment for the designers to make the product successfully interact
with its surrounding technology.
Here will be shown a diagram, with some kind of icon to represent each
separate device or person (processor) and interfaces between the
processors
Library workstation Remote PC
Web - Interface
Integrated Databases

7. Question 2 :- Explain about cost risk, performance risk, and schedule
risk for developing small software project.
Answer :-
▪
Cost risk is the risk that the project costs more than budgeted. It can lead to
performance risk if cost overruns lead to reductions in scope or quality. Cost risk
can also lead to schedule risk if the schedule is extended because not enough funds
are available to complete the project on time.
The main technique used for cost analysis of complex projects is based on
the Work Breakdown Structure (WBS) which organises project tasks into
hierarchical stages or phases.
WBS is a project management technique for defining and organising the total
scope of a project using a hierarchical tree structure. The first two levels, known as
the root node and Level 2, define a set of planned outcomes representing the entire
project scope. At each subsequent level, the children of a parent node represent the
entire scope of their parent node.
A well-designed WBS describes planned outcomes instead of planned actions.
Outcomes are the desired ends of the project and can be predicted accurately,
whereas actions make up the project plan and may be difficult to predict
accurately. A well-designed WBS makes it easy to assign any project activity to
one and only one terminal element of the WBS.
WBS cost estimation attaches a cost to each component and sums these to obtain a
total. Experts in relevant areas are asked to specify a probability distribution for
each part of the WBS and then Monte Carlo simulation is used to estimate a
probability distribution for the total project cost.

8. ▪ PERFORMANCE RISK :-
Performance risk include the risks that the completed project, when complete, fails
to perform as intended or fails to meet business requirements that justified it.
Performance risks can lead to schedule and cost risks if technological problems
increase the duration and cost of the project.
The methods used for schedule and cost risk analysis are similar for all types of
projects, but methods of performance risk analysis can depend more on subject
area. Quantifying the relationships between different aspects of performance can
be difficult.
There have been some attempts to construct quantitative estimates of performance
risk, eg for aerospace systems, but current practice seems to be to use a mix of
quantitative methods and models.
▪ SCHEDULE RISK :-
Schedule risk is the risk that the project takes longer than scheduled. It can lead to
cost risks, as longer projects always cost more, and to performance risk, if the
project is completed too late to perform its intended tasks fully. Apart from the cost
estimation and resource allocation used in CPM, most of the techniques used in
quantitative cost risk analysis are different from those used in schedule risk
analysis.
The earliest technique used for schedule risk analysis was the Gantt chart, but
Gantt charts are not a good method of showing the interrelationship between
tasks, so computers must be used to set up and maintain the network of tasks. One
commonly-used technique is Program Evaluation Review Technique
(PERT) which uses a detailed diagram of all anticipated tasks in a project,
organised into a network to represent the dependence of each task on those that
must precede it.
The Critical Path Method (CPM) is a similar project planning and management
technique which also uses a network representation. Earlier versions did not try to

9. estimate probability distributions for task durations, making it easier to derive the
critical path, ie the set of tasks that determined the final project length. Various
enhancements were made to CPM to allow alternative resource allocations to be
explored, within specified cost constraints.
Stochastic CPM is now the preferred methodology for assessing schedule risk.