A Software Requirements Specification

Software Requirements Specification

Table of Contents

Table of Contents        II

Revision Log        IV

1.        Introduction        1

1.1        Purpose        1

1.2        Document Conventions        1

1.2.1        Abbreviations        1

1.3        Intended Audience        2

1.4        Project Scope        2

1.5        References        2

2.        Overall Description        2

2.1        Product Features        2

2.1.1        Secured Login        3

2.1.2        Inserting new reservations        3

2.1.3        Confirmations        3

2.1.4        Updating existing reservations.        3

2.1.5        Removing existing reservations.        3

2.1.6        Search capabilities.        3

2.2        Known Bugs        3

2.3        Operating Environment        3

2.4        Assumptions and Dependencies        3

3.        Requirements        4

3.1        Login        4

3.1.1        Description        4

3.1.2        Functional Requirements        4

3.2        Flight Reservation        6

3.2.1        Description        6

3.3        New Order Process        8

3.3.1        Description        8

3.3.2        Functional Requirements        8

3.3.3        Error Messages        8

3.3.4        Search for an Order        10

3.3.5        Report generation        11

3.3.6        Graph generation        12

3.3.7        Help Menu        12

3.3.8        About Menu        12

1. Introduction

A Product requirements document is used in product marketing to plan and execute new products.

A Software Requirements Specification is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that users will have with the software.

Use Cases are also known as Functional Requirements. In addition to use cases, the SRS also contains nonfunctional requirements.

The software requirements document is a written statement of what the software will do.

What the software does is directly perceived by its users. When the user performs some action, the software responds in a particular way.

Therefore you must agree on actions the users can perform and response they should expect. This common understanding is captured in the requirements document.

1. Purpose

This document contains the tests requirements for the Automation FR Project.

These software requirements were established by Dani Vainstein.

This SRS specifies to Mercury Flight Application Version 4a.

1. Intended Audience

Project team

Customers

1. Project Scope

This document defines at a functional level the business activities that are encompassed by the system and the rules that apply to them. It also encompasses some of the key high and low level technical requirements of the system.

It draws heavily on both proposed Framework and Business Rules and the Technical Architecture documents.  The scope of the detailed analysis project phase specifies that this document will include.

• Classification of requirements according to their functional areas.
• A description of each process in the system, including their inputs, outputs, and data transformation rules.

1. References

• Databases
  http://www.advancedqtp.com/knowladge-base/scripting-quicktest-professional/adodb/

1. Overall Description

1. Product Features

1. Secured Login

The system supports a secured login user/password.

1. Inserting new reservations

The application should be able to book new flight reservations for a future date requested, destinations and flight selections.

1. Confirmations

The application should be able to  send fax confirmations to clients, about new, updates and cancelled flights.

1. Updating existing reservations.

The application should be able to update any data from an existing reservation.

1. Removing existing reservations.

The application should be able to cancel any existing reservation.

1. Search capabilities.

The application should support a searching mechanism by order number customer name and/or date of flight