EXPERIMENT-2

Aim:
Understanding an SRS.

Requirements:
Hardware Requirements:
• PC with 300 megahertz or higher processor clock speed recommended; 233 MHz minimum
required.

• 128 megabytes (MB) of RAM or higher recommended (64 MB minimum supported)

• 1.5 gigabytes (GB) of available hard disk space

• CD ROM or DVD Drive

• Keyboard and Mouse(compatible pointing device).

Software Requirements:
Rational Rose, Windows XP

Theory:
An SRS is basically an organization's understanding (in writing) of a customer or potential client's
system requirements and dependencies at a particular point in time (usually) prior to any actual
design or development work. It's a two-way insurance policy that assures that both the client and the
organization understand the other's requirements from that perspective at a given point in time.

The SRS document itself states in precise and explicit language those functions and capabilities a
software system (i.e., a software application, an eCommerce Web site, and so on) must provide, as
well as states any required constraints by which the system must abide. The SRS also functions as a
blueprint for completing a project with as little cost growth as possible. The SRS is often referred to
as the "parent" document because all subsequent project management documents, such as design
specifications, statements of work, software architecture specifications, testing and validation plans,
and documentation plans, are related to it.

It's important to note that an SRS contains functional and nonfunctional requirements only; it
doesn't offer design suggestions, possible solutions to technology or business issues, or any other
information other than what the development team understands the customer's system
requirements to be.

A well-designed, well-written SRS accomplishes four major goals:

• It provides feedback to the customer. An SRS is the customer's assurance that the development
organization understands the issues or problems to be solved and the software behavior necessary
to address those problems. Therefore, the SRS should be written in natural language (versus a formal
language, explained later in this article), in an unambiguous manner that may also include charts,
tables, data flow diagrams, decision tables, and so on.

• It decomposes the problem into component parts. The simple act of writing down software
requirements in a well-designed format organizes information, places borders around the problem,
solidifies ideas, and helps break down the problem into its component parts in an orderly fashion.

• It serves as an input to the design specification. As mentioned previously, the SRS serves as the
parent document to subsequent documents, such as the software design specification and statement
of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so
that a design solution can be devised.

• It serves as a product validation check. The SRS also serves as the parent document for testing and
validation strategies that will be applied to the requirements for verification. SRSs are typically
developed during the first stages of "Requirements Development," which is the initial product
development phase in which information is gathered about what requirements are needed--and not.
This information-gathering stage can include onsite visits, questionnaires, surveys, interviews, and
perhaps a return-on-investment (ROI) analysis or needs analysis of the customer or client's current
business environment. The actual specification, then, is written after the requirements have been
gathered and analyzed. SRS should address the following The basic issues that the SRS 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 system’s 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.?

Chracteristics of a good SRS An SRS should be:

a) Correct

b) Unambiguous

c) Complete

d) Consistent

e) Ranked for importance and/or stability

f) Verifiable

g) Modifiable

h) 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 sample of basic SRS Outline

1. Introduction
1.1 Purpose

1.2 Document conventions

1.3 Intended audience

1.4 Additional information

1.5 Contact information/SRS team members

1.6 References

2. Overall Description
 2.1 Product perspective

2.2 Product functions

2.3 User classes and characteristics

2.4 Operating environment

2.5 User environment

2.6 Design/implementation constraints

2.7 Assumptions and dependencies

3. External Interface Requirements

3.1 User interfaces

3.2 Hardware interfaces

3.3 Software interfaces

3.4 Communication protocols and interfaces

4. System Features
4.1 System feature A

4.1.1 Description and priority

4.1.2 Action/result

4.1.3 Functional requirements

4.2 System feature B

5. Other Non-functional Requirements

5.1 Performance requirements

5.2 Safety requirements

5.3 Security requirements

5.4 Software quality attributes

5.5 Project documentation

5.6 User documentation

6. Other Requirements

Appendix A: Terminology/Glossary/Definitions list

Appendix B: To be determined
CONCLUSION:
The SRS was made successfully by following the steps described above.
SAMPLE SRS
Software Requirements Specification

BUS MANAGEMENT
SYSTEM
Table of Content

1. Introduction................................................................................................. 1
1.1 Purpose......................................................................................................... 1
1.2 Product Scope............................................................................................... 1
1.3 References.................................................................................................... 1

2. Overall Description...................................................................................... 2
2.1 Product Functions.......................................................................................... 2
2.2 User Classes and Characteristics.................................................................. 2
2.3 Operating Environment................................................................................ 2
2.4 Design and Implementation Constraints...................................................... 3
2.5 User Documentation.................................................................................... 3
2.6 Assumptions and Dependencies.................................................................. 3

3. External Interface Requirements.................................................................. 4

3.1 User Interfaces.......................................................................................... 4-5
3.2 Hardware Interfaces.................................................................................... 6
3.3 Software Interfaces...................................................................................... 6
3.4 Communications Interfaces......................................................................... 6

4. System Features........................................................................................... 7
4.1 Install Bus Information................................................................................. 7
4.2 Reservation.................................................................................................. 7
4.3 Show Reservation Information..................................................................... 7
4.4 Buses Available............................................................................................ 7

5. Other Nonfunctional Requirements.............................................................. 7

5.1 Performance Requirements.......................................................................... 7
5.2 Security Requirements................................................................................. 8
5.3 Software Quality Attributes.......................................................................... 8

6. Other Requirements..................................................................................... 8

Appendix A: Glossary........................................................................................ 8
1. Introduction
1.1 Purpose
This document describes the software requirements of an online bus booking
system for public transportation. It is intended for designer, developer and
maintainer of the bus booking system. These requirements were created in
response to the problems associated with booking bus tickets via cash.

1.2 Product Scope

The current bus booking system relies on buying tickets from the conductor for
commuting to and fro from a location through public transportation. The task
can be tedious if the number of commuters is large. Also, payment in cash can
be difficult if the payable denominations are uneven. Online Bus Booking
system allows the commuter to either have a specific amount of money on his
Android Based mobile, from which the ticket can be charged. Or, the
commuter can buy the ticket on the bus.

1.3 References

 https://www.youtube.com/watch?v=5FHJyzRpNrE
 http://www.codeincodeblock.com/2012/06/cproject-bus-reservation-
system-in.html
 https://www.phpjabbers.com/bus-reservation-system/
2. Overall Description
2.1 Product Functions
Event Name External Stimuli External Responses Internal Data and
State
Application Opens User opens application Application main System will listen for
screen is displayed when that button is
with a button for the pushed
user to buy a bus
ticket.

Buy ticket request Button to buy ticket is Application will display System will listen for
pressed on the a screen asking user for when that button is
application his/her information pushed
Buy ticket request  Users finished  Users will be  System will check for
submission inputting the data and instructed to wait for a accuracy input and
hits submit on the buy minute while his send answer back to
ticket screen information is checked app

2.2 User Classes and Characteristics

Admins-Must be able to access the database, modify ticket information, verify system working
properly, and handle troubleshooting issues.

Bus Driver- Bus driver must be able to oversee each customer’s input of ticket confirmation number.

Client-Able to buy a ticket, create a ticket that adds to the database.

2.3 Operating Environment

We believe the application will work on 1.x versions of the OS, but our test cases and support only
exists for 2.1 or higher.  We are also assuming that users have a simple understanding of operating
their Android device.  Basic text field entry and typing skills are assumed by all users.

2.4 Design and Implementation Constraints

Reusability - Highly reusable. This application is a framework that can be ported over to any number
of ticket purchasing systems. By Simply changing the Phone App GUI class, it would allow other
transportation systems to use the same back end network code and same phone app for entry to
their own buses or trolleys or subway systems. By keeping our back-end generalized as much as
possible with separate classes that can be reused, the process of adapting the entire application for
a new client will be a very short and purely visual process.

Maintainability - Easily maintainable. This application doesn't require a whole lot of code
modification once it is in place. The only part that really will ever change is what specific passes will
be available for a customer to purchase. Currently we are accounting for "One Time Use," "One Day
Use," "Weekend Use (3 Days)," and "Week Use (7 Days)." If these offerings change, or new ones are
included, the process to maintain the system to the updated services is a short process.

Testability - Quickly testable. This application is generalized and as such has only a few testable
parts. This will enable the testing phase to be very quick and simple. Having only two GUI classes
(phone and bus) simplifies the GUI testing process. Other than the GUI classes, we also have the
Customer and address class which also makes it simpler for unit testing since we won’t have to run a
very large amount of tests. The most difficult tests will involve querying the database and
automating "garbage collection," meaning deleting the expired passes as entries in the database.

Performance - High performance. Both sides of the system, phone and bus, have a single screen
populated by simply test fields. Performance for data entry is dependent upon the programming
language used and the machines implementing the app. This should be negligible. The biggest drag
on performance will be accessing the database. We are keeping our queries simple to counter the
use of mobile broadband connections as our internet access.

Portability - High portability. The entire purpose of this application is to be portable and used by
mobile devices. For this reason, we have decided on a small number of classes so that the code is as
small as it has to be. Users are limited to a android device and must be in an area with mobile
broadband access. Luckily, most areas with bus systems are already equipped with cell towers
allowing at least Edge connection, if not 3g/4g.

Safety - High safety. Customer data is highly confidential and only system administrators have
access to any data in the database. Credit card information will never be stored anywhere, even on
the database, and will be handled by a third party payment company (such as paypal) to ensure
security of payment information.

2.5 User Documentation

Documentation is mainly intended for database administration for understanding how to handle
database entry and editing.  They are expected to understand whatever database administration
program they prefer that supports reading and editing SQLite databases.

On screen instructions will be provided for Phone App users and Bus App users.  No paper
documentation is required.

2.6 Assumptions and Dependencies

We are assuming that all users will be using Android phones with OS version 2.1 or higher.  We
believe the application will work on 1.x versions of the OS, but our test cases and support only exists
for 2.1 or higher.  We are also assuming that users have a simple understanding of operating their
Android device.  Basic text field entry and typing skills are assumed by all users.
3. External Interface Requirements
3.1 User Interfaces

 Phone application interfaces with user

 Using touch input, users select a text field, the phone OS provides data entry
methods

 Inputs:

 First Name - String, 30 characters max, not case sensitive

 Last Name - String, 30 characters max, not case sensitive

 Email - String, 30 characters max, not case sensitive, requires exactly

1 "@" sign and at least 1 "." symbol

 Ticket Type - Drop down menu with "Single Use," "1 Day Pass," "3
Day Pass,"Week Pass." Defaults to "Single Use"

 Credit card type - Drop down menu with "Visa," "Discover,"

"Mastercard," "American Express." Defaults to "Select type."

 Credit card number - String, Exactly 16 numeric characters

 Expiration date month - String, Exactly 2 numeric characters

 Expiration date year - String, Exactly 4 numeric characters

 Phone application interfaces with database

 When sending output "data," database returns 6 digit string "confirmation code"

 Input:

 Confirmation Code - String, 6 digit numeric code assigned by

database as a key when receiving successful "data" input from
Phone App. Sent back to phone application to display on screen

 Using touch input, users touch an image button "Purchase", "Data" output is only
sent once

 Outputs:

 Data - String, all text fields entered as inputs concatenated together,

separated by semicolons

 Database interfaces with phone application

 database receives "data" string

 Input:

 Data - String, all text fields entered on phone concatenated

together, separated by semicolons
  database sends "confirmation code" string back to phone application

 Output:

 Confirmation Code - String, 6 digit numeric code assigned by

database as a key when receiving successful "data" input from
Phone App.

 Bus application interfaces with user

 Using keyboard, users enter "confirmation code" provided upon successful purchase
from phone app

 Input:

 Confirmation Code - String, 6 digit numeric code assigned by

database as a key when receiving successful "data" input from
Phone App.

 Bus application interfaces with database

 When sending output "code," database will return a Boolean indicating successful
removal of given entry from database

 Input:

 Success - Boolean, returned from database, if "True" then display

success message to user.  If "False" display fail message to user.

 Using mouse, users click an image button "Sign In", "Code" output is only sent once

 Output:

 Code - String, 6 digit numeric code, exact copy of "Confirmation

Code."  Sent to database to verify existence of user information

 Database interfaces with Bus application

 database receives "code" string

 Input:

 Code - String, 6 digit numeric code, used to check if string already

exists in database as a key. When found, that entry in database is
removed, and output "success" is returned.

 database sends "success" Boolean back to bus application

 Output:

Success - Boolean, "true" if entry specified by "code" was found and successfully removed.  "False" if
entry specified by "code" was not found.  Database is unchanged if "Success" is false

3.2 Hardware Interfaces

 Phone Application
  must run on android based phone OS Version 2.x.  May work on version 1.x but is
not supported.

 phone must have access to internet via either WiFi or Mobile Broadband

 Bus Application

 must run on windows or mac based computer with keyboard and mouse access. 

 computer must have access to internet via either WiFi or Mobile Broadband

3.3 Software Interfaces

 We will follow typical Java naming convention.
o Number of characters will not exceed 100 characters per line.
o The first character in the variable name wil be lower case as will the following
characters until the secnod word in the variable.
o The first character of all continuing words shall be capitalized.
o No spaces or underscores shall be used in the naming variables.
o The first word and the first character of all following words of the class header shall
be capitalized.
 All data will be stored as Strings in the database.
o The only calculations that will be performed is the search implemented to check the
"code" with all the entry Keys in the database.
o The only other methods that are run are the add and remove methods for entries in
the database

3.4 Communications Interfaces

The system will be developed using Extensible Hypertext Markup Language (XHTML), PHP Hypertext
Preprocessor (PHP), Structure Query Language (SQL), Ajax, Cascading Style Sheet (CSS), and
JavaScript. The relational database was adopted because is made up of a group of logically
connected tables (data that has a relationship to other data). Therefore, establishing a relational
database management system is a great way to increase data integrity, efficiency, ask questions, sort
and filter data, provide stronger security, and share information, ease of use, data independent
among others.
4. System Features
4.1 Install Bus Information

This feature allows you to install a typical bus information before it can be reserved by the
passengers or shown in buses available. It includes the bus no., driver’s name, arrival time,
departure time and destination (from and to) of the bus.

4.2 Reservation

This feature is very simple; it includes the bus no., seat number and the passenger’s name.
The seat number of the particular bus is reserved under the passenger’s name.

4.3 Show Reservation Information

With this feature, you can show all the information regarding the buses and their respective
seats. It contains all the information stored by the previous two function of this project. It
also enlists the no. of empty seats in a bus along with the seat number registered to a
particular passenger. (Scroll down to view the output screen of this feature.

4.4 Buses Available

This feature simply shows the buses available for reservation, and the information regarding
the bus no. stored under the first feature.

5. Other Nonfunctional Requirements

5.1 Performance Requirements

 Response time
o The maximum response time for the submission of a job will be 1 minute.
 Capacity
o The maximum number of jobs schedulable is limited only by the capacity of
the nodes to fulfill the jobs’ deadlines; there is no upper limit inherent in the
Libra scheduler as such.
 Deadline sensitivity
o Assuming submitted statistics for jobs are accurate, the Libra scheduler will
ensure that all jobs are completed with a 10% error allowance.
 Cost sensitivity
o Under all circumstances, the maximum cost payable as submitted by the user
will be the maximum cost charged to the user.
5.2 Security Requirements

Security is used to ensure credit card information as confidential and is not stored anywhere.  The
only location any user data is visible is when users enter in their information.  System Administers
are trained on customer privacy.

5.3 Software Quality Attributes

 After each revision the system will be analyzed and compared with the system requirements
designated by the client. We will than try to break the program with test cases. 

 We will all be responsible for quality assurance.  We will cross-analyze the system
implementation with the System Requirements to verify system accuracy.  

 All final documents will be reviewed for spelling errors, broken links, and any other issues
that affect the quality of the document.  Any errors found in either the system or supporting
documents will be fixed at the time errors are found. 

6. Other Requirements
● Database: A database is required to store all the details of patients, bandages and other
personal details of patients like blood group etc. It can also be stored in excel sheet for
temporary time and then uploaded to database of the organization.

● Server: To Process all the request from the user.

● Antivirus: For security purposes, antivirus must be installed.

● Internet:Good speed of network is mandatory to get up to date about the process.

Appendix A: Glossary
 SDD: Software Design
 Document Server: The main computer on a network.
 SPMP: Software Project Management Plan
 SRS: Software Requirements Specification
 Web: the network of computers that forms the Internet
 FAQ: Frequently Asked Questions.
 IEEE: Institute of Electrics & Electronics Engineering IS: Information Systems
 IT: Information Technology