SOFTWARE REQUIREMENT SPECIFICATION:

 Requirements document present on overview of product features and summaries the processing
requirement for development operation and maintance of product.
 The format of software requirement specification are presented as follows,
1) Product overview and summary
2) Development operating and maintance
3) External interfaces and data flow
4) Functional requirement
5) Performance requirement
6) Exception handling
7) Early subset and implementation properties
8) Foreseeable modification and enchancement
9) Acceptance criteria
10) Design hints and guide lines
11) Cross reference syntax
12) Glossary of terms.

(1) System Requirement Specification

 It contains a complete information description, a detailed functional description, a representation
of system behaviour, an indication of performance requirements and design constraints,
appropriate validation criteria, and other information pertinent to requirements.
 Software requirement specification (SRS) is a document that completely describes what the proposed
software should do without describing how software will do it.
 The basic goal of the requirement phase is to produce the SRS, Which describes the complete
behaviour of the proposed software.
 SRS is also helping the clients to understand their own needs.

Characteristics of an SRS
Software requirements specification should be accurate, complete, efficient, and of high quality, so that it does
not affect the entire project plan. An SRS is said to be of high quality when the developer and user easily
understand the prepared document. Other characteristics of SRS are discussed below.
Correct
 SRS is correct when all user requirements are stated in the requirements document.
 The stated requirements should be according to the desired system.
 This implies that each requirement is examined to ensure that it (SRS) represents user requirements.
  Note that there is no specified tool or procedure to assure the correctness of SRS. Correctness
ensures that all specified requirements are performed correctly.
Unambiguous
 SRS is unambiguous when every stated requirement has only one interpretation.
 This implies that each requirement is uniquely interpreted.
 In case there is a term used with multiple meanings, the requirements document should
specify the meanings in the SRS so that it is clear and easy to understand.
Complete
 SRS is complete when the requirements clearly define what the software is required to do.
 This includes all the requirements related to performance, design and functionality.
Ranked for importance/stability
 All requirements are not equally important, hence each requirement is identified to make
differences among other requirements.
 For this, it is essential to clearly identify each requirement. Stability implies the probability of
changes in the requirement in future.
Modifiable
 The requirements of the user can change, hence requirements document should be created in such a
manner that those changes can be modified easily, consistently maintaining the structure and style
of the SRS.
Traceable
 SRS is traceable when the source of each requirement is clear and facilitates the reference of
each requirement in future.
 For this, forward tracing and backward tracing are used.
 Forward tracing implies that each requirement should be traceable to design and code elements.
 Backward tracing implies defining each requirement explicitly referencing its source.
Verifiable
 SRS is verifiable when the specified requirements can be verified with a cost-effective
process to check whether the final software meets those requirements.
 The requirements are verified with the help of reviews. Note that unambiguity is essential for
verifiability.
Consistent
 SRS is consistent when the subsets of individual requirements defined do not conflict with
each other.
 For example, there can be a case when different requirements can use different terms to refer
to the same object.
 There can be logical or temporal conflicts between the specified requirements and some
requirements whose logical or temporal characteristics are not satisfied.
 For instance, a requirement states that an event 'a' is to occur before another event 'b'. But then
another set of requirements states (directly or indirectly by transitivity) that event 'b' should
occur before event 'a'.
(2) Functional and Non-Functional Requirements
Functional requirements
 These describe the functionality of a system -- how a system should react to a particular set of
inputs and what should be the corresponding output.
 Given a problem statement, the functional requirements could be identified by focusing on the
following points:
̶ Identify the high level functional requirements simply from the conceptual understanding of
the problem. For example, a Library Management System, apart from anything else, should be
able to issue and return books.
̶ Identify the cases where an end user gets some meaningful work done by using the system.
For example, in a digital library a user might use the "Search Book" functionality to obtain
information about the books of his interest.
̶ If we consider the system as a black box, there would be some inputs to it, and some output
in return. This black box defines the functionalities of the system. For example, to search for
a book, user gives title of the book as input and get the book details and location as the
output.
̶ Any high level requirement identified could have different sub-requirements. For example,
"Issue Book" module could behave differently for different class of users, or for a particular
user who has issued the book thrice consecutively.
Non-Functional requirements
 They are not directly related what functionalities are expected from the system.
 However, NFRs could typically define how the system should behave under certain situations.
 For example, a NFR could say that the system should work with 128MB RAM.
Product requirements
 Requirements which specify that the delivered product must behave in a particular way e.g.
execution speed, reliability, etc.
Organisational requirements
 Requirements which are a consequence of organisational policies and procedures e.g. process
standards used, implementation requirements, etc.
External requirements
 Requirements which arise from factors which are external to the system and its development process
e.g. interoperability requirements, legislative requirements, etc.

Example:
Functional Requirements for Hotel Management System
1. Reservation/Booking
1.1. The system shall record reservations.
1.2. The system shall record the customer’s first name.
1.3. The system shall record the customer’s last name.
1.4. The system shall record the number of occupants.
1.5. The system shall record the room number.
1.6. The system shall display the default room rate.
1.7. The system shall record the customer’s phone number.
1.8. The system shall display whether or not the room is guaranteed.
1.9. The system shall generate a unique confirmation number for each reservation.
1.10. The system shall record the expected check-in date and time.
1.11. The system shall record the expected checkout date and time.
1.12. The system shall check-in customers.
 1.13. The system shall allow reservations to be modified without having to reenter all the
customer information.
1.14. The system shall checkout customers.
1.15. The system shall charge the customer for an extra night if they checkout after 11:00 a.m.
1.16. The system shall mark guaranteed rooms as “must pay” after 6:00 pm on the check-
in date.
1.17. The system shall record customer feedback.
2. Food
2.1. The system shall track all meals purchased in the hotel (restaurant and room service).
2.2. The system shall record payment and payment type for meals.
2.3. The system shall bill the current room if payment is not made at time of service.
2.4. The system shall accept reservations for the restaurant and room service.
3. Management
3.1. The system shall display the hotel occupancy for a specified period of time (days;
including past, present, and future dates).
3.2. The system shall display projected occupancy for a period of time (days).
3.3. The system shall display room revenue for a specified period of time (days).
3.4. The system shall display food revenue for a specified period of time (days).
3.5. The system shall display an exception report, showing where default room and food
prices have been overridden.
3.6. The system shall allow for the addition of information, regarding rooms, rates, menu
items, prices, and user profiles.
3.7. The system shall allow for the deletion of information, regarding rooms, rates, menu
items, prices, and user profiles.
3.8. The system shall allow for the modification of information, regarding rooms, rates,
menu items, prices, and user profiles.
3.9. The system shall allow managers to assign user passwords.

Non-Functional Requirements for Hotel Management System

1 The load time for user interface screens shall take no longer than two seconds.
2 The log in information shall be verified within five seconds.
3 Queries shall return results within five seconds.
4 The Hotel Management System shall be a stand-alone system running in a Windows environment.
5 The system shall be developed using Java platform.
6 There shall be consistency in variable names within the system.
7 The graphical user interface shall have a consistent look and feel.
8 Specify the factors required to establish the required reliability of the software system at
time of delivery.
9 The system shall be available during normal hotel operating hours.
10 Customer Service Representatives and Managers will be able to log in to the Hotel Management
System. Customer Service Representatives will have access to the Reservation/Booking and Food
subsystems. Managers will have access to the Management subsystem as well as the
Reservation/Booking and Food subsystems.
11 Access to the various subsystems will be protected by a user log in screen that requires a user
name and password.
(3) Feasibility Study
Feasibility study establishes the basic business requirements and constraints associated with the application to be
built and then assesses whether the application is a viable candidate for the process.

Types of Feasibility Study

Technical feasibility
 In technical feasibility analysis, alternatives for hardware, software and general design approach
are determined to be available, appropriate, and functional.
The technical issues raised during the feasibility study are:
a) Does the necessary technology exist?
b) Does the proposed equipment have the technical capacity to hold the data required to use the
new system?
c) Will the proposed system and components provide adequate responses to enquires, regardless of
the number of location of users?
d) Can the system be expanded, if developed?
e) Are there technical guarantees of accuracy, reliability, ease of access and data security?
Operational feasibility
 Operational feasibility study tests the operational scope of the software to be developed. The
proposed software must have high operational feasibility. The usability will be high.
 Operational feasibility is dependent on human resources available for the project and involves
projecting whether the system will be used if it is developed and implemented.
 Operational feasibility is a measure of how well a proposed system solves the problems, and takes
advantage of the opportunities identified during scope definition and how it satisfies the
requirements identified in the requirements analysis phase of system development.
The essential questions that help in testing the operational feasibility of a system include the following:
a) Does current mode of operation provide adequate throughput and response time?
b) Does current mode provide end users and managers with timely, pertinent, accurate and useful
formatted information?
c) Does current mode of operation provide cost-effective information services to the business?
d) Could there be a reduction in cost and or an increase in benefits?
e) Does current mode of operation offer effective controls to protect against fraud and to
guarantee accuracy and security of data and information?
f) Does current mode of operation make maximum use of available resources, including people, time,
and flow of forms?
g) Does current mode of operation provide reliable services
h) Are the services flexible and expandable?
i) Are the current work practices and procedures adequate to support the new system?
j) If the system is developed, will it be used?
k) Manpower problems, Labour objections, Manager resistance, Organizational conflicts and policies,
Government regulations
l) Does management support the project?
m) Are the users not happy with current business practices?
n) Will it reduce the time (operation) considerably?
o) Have the users been involved in the planning and development of the project?
p) Will the proposed system really benefit the organization?
Economic feasibility
 The economic feasibility study evaluate the cost of the software development against the
ultimate income or benefits gets from the developed system.
 There must be scopes for profit after the successful Completion of the project.
Possible questions raised in economic analysis are:
a) Is the system cost effective?
b) Do benefits outweigh costs?
c) The cost of doing full system study
d) The cost of business employee time
e) Estimated cost of hardware
f) Estimated cost of software/software development
g) Is the project possible, given the resource constraints?
h) What are the savings that will result from the system?
i) Cost of employees' time for study.
j) Cost of packaged software/software development.