Rafia Fatima 70068018

Mahnoor Athar 70067022

 <Project Name>

Object Oriented Software Engineering

Assignment # 02
Due Date: 02-04-2021 Section: Total Marks: 100
Program: BS(SE)
Instructions
I can take either quiz or in class viva for this assignment by calling any one on the white board to
solve any question of the assignment. Copied assignment will be getting zero marks and further
action will be taken as per university policy.

Software Requirements Specification Template

CptS 322—Software Engineering
25 Feb, 2020

The following annotated template shall be used to complete the Software Requirements
Specification (SRS) assignment of WSU-TC CptS 322. The instructor must approve any
modifications to the overall structure of this document.

Template Usage:
Text contained within angle brackets (‘<’, ‘>’) shall be replaced by your project-specific
information and/or details. For example, <Project Name> will be replaced with either ‘Smart
Home’ or ‘Sensor Network’.

Italicized text is included to briefly annotate the purpose of each section within this template.
This text should not appear in the final version of your submitted SRS.

This cover page is not a part of the final template and should be removed before your SRS is
submitted.

Acknowledgements:
Sections of this document are based upon the IEEE Guide to Software Requirements
Specification (ANSI/IEEE Std. 830-1984). The SRS templates of Dr. Orest Pilskalns (WSU,
Vancover) and Jack Hagemeister (WSU, Pullman) have also be used as guides in developing this
template for the WSU-TC Spring 2005 CptS 322 course.

Software Requirements Specification Page ii

 <Project Name>

Table of Contents

REVISION HISTORY................................................................................................................................................ II
DOCUMENT APPROVAL ........................................................................................................................................ II
3. SPECIFIC REQUIREMENTS ............................................................................................................................... 1
3.1 EXTERNAL INTERFACE REQUIREMENTS ............................................................................................................... 1
3.1.1 User Interfaces ............................................................................................................................................ 1
3.1.2 Hardware Interfaces .................................................................................................................................... 1
3.1.3 Software Interfaces ...................................................................................................................................... 1
3.1.4 Communications Interfaces ......................................................................................................................... 1
3.2 FUNCTIONAL REQUIREMENTS .............................................................................................................................. 2
3.2.1 <Functional Requirement or Feature #1>.................................................................................................. 2
3.2.2 <Functional Requirement or Feature #2>.................................................................................................. 2
3.3 USE CASES ........................................................................................................................................................... 4
3.3.1 Use Case #1 ................................................................................................................................................. 5
3.3.2 Use Case #2 ................................................................................................................................................. 6
3.4 CLASSES / OBJECTS .............................................................................................................................................. 9
3.4.1 <Class / Object #1> .................................................................................................................................. 10
3.4.2 <Class / Object #2> .................................................................................................................................. 10
3.5 NON-FUNCTIONAL REQUIREMENTS ................................................................................................................... 10
3.5.1 Performance .............................................................................................................................................. 11
3.5.2 Reliability .................................................................................................................................................. 11
3.5.3 Availability ................................................................................................................................................ 11
3.5.4 Security ...................................................................................................................................................... 11
3.5.5 Maintainability .......................................................................................................................................... 11
3.5.6 Portability .................................................................................................................................................. 11
3.6 INVERSE REQUIREMENTS ................................................................................................................................... 11
3.7 DESIGN CONSTRAINTS ....................................................................................................................................... 11
3.8 LOGICAL DATABASE REQUIREMENTS ................................................................................................................ 12
3.9 OTHER REQUIREMENTS ...................................................................................................................................... 12

Software Requirements Specification Page iii

 <Project Name>

3. Specific Requirements
This will be the largest and most important section of the SRS. The customer requirements will
be embodied within Section 2, but this section will give the D-requirements that are used to
guide the project’s software design, implementation, and testing.

Each requirement in this section should be:

• Correct
• Traceable (both forward and backward to prior/future artifacts)
• Unambiguous
• Verifiable (i.e., testable)
• Prioritized (with respect to importance and/or stability)
• Complete
• Consistent
• Uniquely identifiable (usually via numbering like 3.4.5.6)

Attention should be paid to the carefully organize the requirements presented in this section so
that they may easily accessed and understood. Furthermore, this SRS is not the software design
document, therefore one should avoid the tendency to over-constrain (and therefore design) the
software project within this SRS.

3.1 External Interface Requirements

3.1.1 User Interfaces
Our interface is really fascinating to provide tourist an enthusiastic theme with combinations of
colors and artistic view so they will be more attracted towards it. Moreover, we aim to provide
them a very friendly interface so they don’t face any difficulty while using it.

3.1.2 Hardware Interfaces

It is a web-based application so no specification is really required a good internet, 1 gigahertz
processor, 1GB RAM, 512 MB storage will be enough.

3.1.3 Software Interfaces

Its web-based application and will be available for all platforms. E.g.,
▪ Windows
▪ Mac OS
▪ Linux
▪ Android
3.1.4 Communications Interfaces
Whenever user signs up (fills personal details), choose packages or deals etc., and at the end fills
out financial details then all of this data is stored in database and also, we have options to
redirect users to other pages so good internet connection will be required.

Software Requirements Specification Page 1

 <Project Name>

3.2 Functional Requirements

Following are the functional requirements involved in our website.

3.2.1 <Feature #1: Sign Up and Login>

3.2.1.1 Introduction
User should register first with the help of sign up and then log in to be a member of R&M
Planes.

3.2.1.2 Inputs
In input form user will enter name, email address, Phone number and Interests. User can also log
in through Gmail and Facebook.

3.2.1.3 Processing
System will process that the information provide is in correct format or not, Phone no will be
verified by sending code to the number and Gmail will be verified by sending code to the email
provided by user. After all the verifications are done data is stored in database.

3.2.1.4 Outputs
In output user will become member of R&M Planes. And the services provided by R&M Planes
and content will be showed to user.

3.2.1.5 Error Handling

If the details entered by user are incorrect the system will discard the information and ask the
user to enter again.

3.2.2 <Feature #2: Ask user to register a seat>

3.2.1.1 Introduction
System will ask user on what date or time he want to go, then he will be asked from which
airline and type of seat he will choose.

3.2.1.2 Inputs
In input date and time, airline and seat type will be saved.

3.2.1.3 Processing
System will check according to particular date and time if any seat is available and if available
then which airlines and in airline what type of seats are available.

3.2.1.4 Outputs
User will be showed about the hotel bookings and deals and packages we will provide them.

3.2.1.5 Error Handling

If the details entered by user are incorrect the system will discard the information and ask the
user to enter again.

Software Requirements Specification Page 2

 <Project Name>

3.2.3 <Feature #3: Ask user to avail deals and packages>

3.2.3.1 Introduction
System will ask user related to booking for hotel and tour guide according to the place user is
going. If user shows interest then system will also show them complete package with seat and
hotel booking also. Otherwise user will be directly showing financial details for booking.

3.2.3.2 Inputs
In input name of hotel and no of days will be saved.

3.2.3.3 Processing
System will ask user related to booking for hotel and tour guide according to the place user is
going. If user shows interest then system will also show them complete package with seat and
hotel booking also. Otherwise user will be directly showing financial details for booking.

3.2.3.4 Outputs
User will be showed financial detail form.

3.2.3.5 Error Handling

If the details entered by user are incorrect the system will discard the information and ask the
user to enter again.

3.2.4 <Feature #4: Ask user to enter financial details >

3.2.4.1 Introduction
After user has selected all the services he wants to get availed he will be asked about financial
details to confirm his seat.

3.2.4.2 Inputs
Debit Card number, Card holder name and Amount that will be deducted.

3.2.4.3 Processing
System will ask user and show a form to enter financial details and will store in database and
give them a receipt.

3.2.4.4 Outputs
Receipt will be generated and shared with them.

3.2.4.5 Error Handling

If the details entered by user are incorrect the system will discard the information and ask the
user to enter again.

3.2.5 <Feature #5: Feedback>

3.2.5.1 Introduction
After user has entertained with all of our services he will be asked about feedback that will be
shared with other users.

Software Requirements Specification Page 3

 <Project Name>

3.2.5.2 Inputs
5-star rating, description about experience.

3.2.5.3 Processing
System will ask user to rate the system and write something about the system.

3.2.5.4 Outputs
Thankyou message will pop up.

3.2.5.5 Error Handling

If the details entered by user are incorrect the system will discard the information and ask the
user to enter again.

3.3 Use Cases

Software Requirements Specification Page 4

 <Project Name>

3.3.1 Use Case #1

Use Case ID: 1

Use Case Name: Provide Rights
Date Created: Feb 25, 2020
Actors: Admin
Description: Admin is responsible to give tasks to the actors.

Preconditions: 1. Customer should have opened the website

2. The customer should have requested for sign up
Post conditions: 1. System must have added the record of the customer in the database

Normal Flow:
Customer System
1. System will prompt the
customer to enter basic
information
2. Customer will enter the basic
information
3. System will verify that the
entered CNIC number is not
in the database
4. System will prompt the
customer to set a new
password and verify
5. The customer will enter a new
password and will re-enter it
6. If both entered passwords
match and satisfy password
requirements then create an
account for the customer
Alternative Flows: There is no person to give rights for a specific task.
Exceptions: None.

Software Requirements Specification Page 5

 <Project Name>

Use Case ID: 2

Use Case Name: Reports
Date Created: Feb 25, 2020
Actors: Admin
Description:Reports generated related to bookings finance and other
website traffic can be seen by admin.
Preconditions: 1. Administrator wants to view the reports for analysis.

Post conditions: 1. Reports are viewed by admin.

Normal Flow:
Admin System
When admin needs to perform
analysis.

System will view the report.

Then generate analysis.

Alternative Flows: Reports are not generated.

Exceptions: None.

Use Case ID: 3

Use Case Name: Sign-up/ Sign In
Date Created: Feb 25, 2020
Actors: Admin
Description: User will open website then sign in using Google, Instagram and
Facebook and then sign in.
Preconditions: Customer should have opened the website.

Post conditions: User is now a member of R&M PLANES.

Normal Flow:
Customer System
User open the website.

User is showed half of the services

provided by the website and asked

Software Requirements Specification Page 6

 <Project Name>

to sign up for further exploring.

Then User is shown sign up

form.

After signing up he presses submits

and sign in form is showed.
The customer will become
member
Alternative Flows: User do not click on submit button.
Exceptions: None.

Use Case ID: 4

Use Case Name: Search/ Choose from Options
Date Created: Feb 25, 2020
Actors: Admin
Description:After signing in User will be shown many options for
booking related to their interests.
Preconditions: 1. User must register first.

Post conditions: 1. User has chosen these options.

Normal Flow:
User System
User opens the website.

User signs in.

Then User is shown multiple

options and contents

Alternative Flows: User do not click on submit button.

Software Requirements Specification Page 7

 <Project Name>

Exceptions: None.

Use Case ID: 5

Use Case Name: Booking
Date Created: Feb 25, 2020
Actors: Admin
Description:After choosing desired options, User will be shown a
form for his bookings related to airplane.
Preconditions: 1. User must have chosen the place to go and other packages like hotels
etc.
Post conditions: 1. User has chosen these options.

Normal Flow:
User System
User opens the website.

User signs in.

Then User is shown multiple

options and contents

After choosing the options User

is shown plane bookings.

User have to select by which plane

he’ll go and on what dates.

Alternative Flows: User needs a time when no plane is available.

Exceptions: User have not selected any option.

Use Case ID: 6

Use Case Name: Feedback
Date Created: Feb 25, 2020
Actors: Admin
Description:After enjoying all the services provided by the website
User will be shown feedback form.
Preconditions: 1. User must have booked the seat.

Software Requirements Specification Page 8

 <Project Name>

Post conditions: 1 User has booked.

Normal Flow:
User System
User opens the website.

User signs in.

User books the seat.

User is shown the feedback

form.

Alternative Flows: User faces problem booking.

Exceptions: Connection Failed, Server Down.

Use Case ID: 7

Use Case Name: Feedback
Date Created: Feb 25, 2020
Actors: Database
Description:Users details when they fill sign up form, booking and form will be saved
and kept as backup also.
Preconditions: 1. User must have signed up.

Post conditions: 1 User has signed up and booked.

Normal Flow:
User System
User opens the website.

User signs in.

User books the seat.

User gives feedback.

Alternative Flows: None

Exceptions: Connection Failed, Server Down.

Software Requirements Specification Page 9

 <Project Name>

Use Case ID: 8

Use Case Name: Keeps Backup
Date Created: Feb 25, 2020
Actors: Database
Description: Activities performed by User for example signing in
booking details and giving feedback if submit is not
pressed will be autosaved and passwords also will be kept
as backup.
Preconditions: 1. User must have performed activities.
Post conditions: 1 None.
Normal Flow:
User System
User opens the website.

User signs in.

User books the seat.

User gives feedback.

Alternative Flows: None

Exceptions: Connection Failed, Server Down.

3.4 Classes / Objects

3.4.1 <Class / Object #1>

3.4.1.1 Attributes
3.4.1.2 Functions
<Reference to functional requirements and/or use cases>
3.4.2 <Class / Object #2>
…

3.5 Non-Functional Requirements

Non-functional requirements may exist for the following attributes. Often these requirements
must be achieved at a system-wide level rather than at a unit level. State the requirements in the
following sections in measurable terms (e.g., 95% of transaction shall be processed in less than
a second, system downtime may not exceed 1 minute per day, > 30-day MTBF value, etc).

Software Requirements Specification Page 10

 <Project Name>

3.5.1 Performance
Customer can only go to next step only if he completes first step that’s why there will be not
much loading issues.

3.5.2 Reliability
As we’re giving them all in one package to the users so a lot of their time will be saved as they
will not need to waste time searching on other websites. And for security purpose we’re
providing them bank evidence.

3.5.3 Availability
It is web-based application and will be available 24/7.

3.5.4 Security
As discussed in Use Case users will have to provide financial detail, so we’re connecting them
directly to their back database and bank will deduct their amount and generate them receipt that
will be provided to users by our website.

3.5.5 Maintainability
Maintenance will involve adding more new features for betterment of experience and fixing of
bugs.

3.5.6 Portability
As it is a web-based application so it will be available for all kinds of operating system.

3.6 Inverse Requirements

• Ticket Reservation system mainly consists of the Users, which can be further classified
into the customer and administrator of the Airline Reservation System website.
•
• The customer and the system need to check the feasibility of flight connections and
their schedule.

• The system shall automatically do month selection when numbers are enter.

3.7 Design Constraints

Design constraints can have a significant impact on the design and should be validated prior to
imposing them on the solution.
Design constraints can be imposed by other standards, hardware limitations, etc.
Specify the requirements derived from existing standards or regulations. Theymight include:
Software Requirements Specification Page 11
 <Project Name>

(1) Report format

(2) Data naming
(3) Accounting procedures
(4) Audit Tracing.
There are a number of quality characteristics that can apply to software like efficiency,
correctness, flexibility, maintainability, integrity, reliability, usability and reusability.

3.8 Logical Database Requirements

Logical database requirements should specify the logical requirements for any information that
is to be placed in a database. This may include the following:

• Types of information used by various functions;

• Frequency of use;
• Accessing capabilities
• Data entities and their relationships
• Integrity constraints
• Data retention requirements

3.9 Other Requirements

• Associate every online booking with an account.

• Limit every account to a single user.
• Enable users to search and find the most relevant booking options.
• Users should be helped appropriately to fill in the mandatory fields in case of invalid input.

Software Requirements Specification Page 12