biltenfvd

T E X A S D E P A R T M E N T O F I N F O R M A T I O N R E S O U R C E S

Software RequirementsSpecification

Template

Version 1.0 ● 24 MAY 2006

NOTE: Please remove this page when creating a Software Requirements Specification document.

Texas Project Delivery Framework SOFTWARE REQUIREMENTS SPECIFICATION

Using This TemplateThe companion document, Software Requirements Specification Instructions, provides detailed direction for completing this template. This and other Framework documents, including a glossary, are available at www.dir.state.tx.us/pubs/framework/.

To create a document from this template:

1. Delete the template title page (previous page) and this page.

2. Replace [bracketed text] on the cover page (next page) with your project and agency information.

3. Replace [bracketed text] in the document header area at the top of page i (Contents page) with the same project and agency information as on the cover page.

Note: Please do not remove or modify content in the footer area.

4. Complete the entire template. Each section contains abbreviated instructions and a content area. The content area is marked with a placeholder symbol () or with a table. Relevant text from other project documents may be pasted into content areas.

5. Update the table of contents by right-clicking and selecting “Update Field,” then “Update Page Numbers Only.”

NOTE: Please remove this page when creating a Software Requirements Specification document.

DIR Document 25SR-T1-0

http://www.dir.state.tx.us/pubs/framework/

TEXAS PROJECT DELIVERY FRAMEWORK

SOFTWAREREQUIREMENTS SPECIFICATION

BransysFLEMAN

VERSION: [Version Number] REVISION DATE: [Date]

Approver Name Title Signature Date

Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]

Contents1.1 Purpose..............................................................................................11.2 Business Context...............................................................................11.3 Scope.................................................................................................11.4 User Characteristics...........................................................................22.1 Assumptions......................................................................................32.2 Dependencies....................................................................................32.3 Constraints.........................................................................................34.1 Business Requirements.....................................................................44.2 Functional Requirements...................................................................43.3 Logical Data Requirements................................................................53.4 User Requirements............................................................................53.5 Information Management Requirements............................................53.6 Systems Requirements......................................................................53.7 Interfaces...........................................................................................63.8 Other Requirements...........................................................................6

Based onDIR Document 25SR-T1-0 Page i


Section 1. Overview1.1 Purpose

The purpose of this software is easier to work with dispatcher part of a taxi company.This document shall be used by:

Customers-to be assured that all requirements was met

Designers and developers-to design and develop proper solution

Test responsible-to create and execute test cases for different scenarios

Document writer-to write proper documentation

1.2 Business Context

The application is intended to be used in taxi companies in the process of incoming calls and realizing them. You can also reserve a ride that will help you to send a car on time that the customer wants. You can make a different type of reports.

This application shall ease and optimize the working process for all employees in the taxi companies. An additional standardization of the working procedures shall be introduced, improving the security issue at the same time.

1.3 Scope

The project will consists of three parts, intended to be used with different scope of the working procedures in taxi companies.

Calls – for accepting calls, realizing them, sending cars to predefined client, calling customers who send a signal from mobile

Alarms – sending cars on predefined time

Reports – give full control of the work done

1.4 User Characteristics

The following users shall use the application:

Dispatcher operator responsible for receiving calls, making calls, realizing received calls, sending correct type of cars for VIP customer, for customer with special wishes (like driving man with special needs, driving your pet) etc.

Managers can view different type of reports, and with that can compare work previously done with the current.

Based onDIR Document 25SR-T1-0 Page 1


Section 2. Assumptions, Dependencies, Constraints2.1 Assumptions

Describe the assumptions that can affect the requirements specified in this SRS.

2.2 Dependencies

Describe the dependencies that can affect the requirements specified in this SRS.

2.3 Constraints

Describe the constraints that can affect the requirements specified in this SRS.



Section 3. Use cases model 3.1 Logged in

Name Logging in

Context of use For using this software, user must to start the software

Actors Dispatcher, manager

Trigger

The dispatcher or the manager for using this software must to have predefined username and password if they don’t have they will can’t use it

Success result The dispatcher or the manager is logged in the software

Pre conditions The software must be installed on the system

Main success scenario

1. The user starts the software.

2. The user wrote the correct username and password in the text boxes

3. Click on the button enter

4. The user is logged in

Extensions

2.1 The user entered wrong username or password

2.2 Until the user entered correct username and password can’t be logged in

Related information

3.2 Taking passenger and realizing call

Name Taking a passenger and realizing call

Context of useWhen passenger is calling, dispatcher is answering and sending car to the passenger wanted destination

Actors Dispatcher, driver, passenger

Trigger The passenger calling at the dispatcher center. And the dispatcher



sending taxi to the wanted destination.

Success resultThe passenger entered in taxi, driver drive the passenger to wanted location and the passenger paying for the drive.

Pre conditionsIt must to have installed software on their computer, phone near dispatcher, and taxi car on the terrain


1. Passenger is calling in dispatcher center

2. Dispatcher answered on the call.

3. Passenger want a car on desired destination.

4. The dispatcher confirm the call and call the taxi car on terrain

5. The dispatcher transferred to the driver where to go.

6. Taxi driver accept the call and go to wanted destination.

7. When taxi is at wanted destination, the passenger entered in the taxi

8. The driver takes passengers to the wanted destination.

9. Passenger pays the driver

Extensions

4.1 Destination is so far, and the dispatcher tell to the passenger that the car will arrive after later time that passenger want

4.1.a If passenger want the car the call will be realized

4.1.b If passenger don’t want the car after offered time the call will be canceled

6.1 Driver if it want can reject the call

6.1.a Because is too far from the destination6.1.b Because driver don’t want to drive that passenger learned from previous experiences

Related information

3.3 Taking passenger from the stop



Name Taking a passenger from stop

Context of use Driver drive passenger which entered on stop, not from call

Actors Dispatcher, driver, passenger

TriggerThe driver is waiting on stop. Passenger is entering in the car. And driver takes passenger to wanted destination.

Success resultDriver reporting drive to the dispatching center, the passenger paying for the drive

Pre conditionsIt must to have installed software on their computer, phone near dispatcher, and taxi car on stop ready for driving


1. Driver is waiting at the stop

2. Passenger enter in the car

3. Passenger tell the driver where wants to go.

4. Driver report the drive to dispatching center.

5. The dispatcher enter that drive in the software with pressing F5 and add from where, to where, car number, client or not, taximeter or without

6. The driver takes passengers to the wanted destination.

7. Passenger pays the driver

Extensions4.1 Driver can’t report the drive and that drive will not be in the software

Related information

3.4 Canceling the call

Name Canceling the call

Context of use The passenger is calling the dispatcher and canceled the previous call

Actors Dispatcher, passenger

Trigger The dispatcher cancel the call

Success result When the call will be successful



Pre conditionsIt must to have installed software on their computer, phone near dispatcher


1. The passenger is calling the dispatching center

2. Told to the dispatcher to cancel the previous call

3. The dispatcher is looking for the same call in the grid

4. After that the call is selected from the dispatcher

5. And cancel the call with note for what is the reason because call is canceled

Extensions

Related information

3.5 Info call

Name Info call

Context of useThe passenger is calling the dispatcher for information about car or about some route

Actors Dispatcher, passenger

Trigger The passenger call the dispatcher only for some information

Success result When the call will be successful marked as info call

Pre conditionsIt must to have installed software on their computer, phone near dispatcher


1. The passenger is calling the dispatching center

2. Ask about some information

3. The dispatcher is looking the call in the grid

4. After that the call is selected from the dispatcher

5. And marked as info call with note for what passenger is looking for

Extensions



Related information

Name

Canceling a previously paid-in ticket

Context of use

Upon creating a ticket it’s possible the cashier and/or clients to make some mistake, or the ticket were paid-in, but a fiscal bill was not printed (due to some problem with fiscal printer). In this case the played ticket, and the received payment can be canceled

Actors Cashier

TriggerThe cahier and/or client have made mistake during the creation of the ticket, or a fiscal bill was not printed

Success result The ticket is canceled. The paid amount is refunded

Pre conditions The cahier is logged in the systems


10. The user initiates action of canceling a previously paid-in ticket

11. A form for canceling the ticket is displayed

12. The user inputs the number of the ticket to be canceled

13. System checks if the ticket exists and can be canceled and if so, the information from the ticket are displayed on the form and the buttons for cancelation are enabled

14. The user chooses the option for canceling the ticket

15. The system informs about successfully performed action.

16. The ticket is canceled and the payment is refunded

Extensions 4.1 The system finds out that ticket with that number does not exists

Use case continue from step 2

4.2.a Some of the matches included on the ticket are already



started

4.2.b Information from the ticket are displayed, with the started matches marked with red color


5.1.a The user chooses the option for canceling the ticket and opening again

5.1.b Ticket is canceled and the payment is refunded

5.1.c The system opens the screen for creation tickets/payments with data from the previous ticket (the ticket that was canceled)

5.2.a The user abort the cancelation ticket action

5.2.b The ticket is not canceled and the payment is not refunded

Related information

3.2 Paying-out a winning ticket in Desktop application

Name Paying-out a winning ticket in Desktop application

Context of use

When a ticket is winning, the gain (total amount which depends of the played games and their odds) should be played-out to the customer (client)

Actors Cashier

TriggerThe customer have came to the sport betting company claiming to poses a winning ticket that needs to be paid-out

Success resultThe gain is paid-out and his amount is added to the total paid-out amount (from all wining and paid-out ticket)

Pre conditions The cahier is logged in the systems

Main success scenario 1. The user initiates action of paying-out a winning ticket

2. A form for paid-out a ticket is displayed



3. The user inputs the number of the ticket to be paid-out

4. System checks if the ticket exists and is a winning ticket and if so, the information from the ticket are displayed on the form and the button for paying-out is enabled. The amount for payment is displayed on the form

5. The user chooses the option for paying-out the ticket

6. The system informs about successfully performed action.

7. The ticket is paid-out and his amount is added to the total paid-out amount

Extensions

4.1 The system finds out that ticket with that number does not exists


4.2.a Some of the matches required to be winning, included on the ticket, actually are not

4.2.b Information from the ticket are displayed, with the missed matches marked with red color


5.1.a The user chooses the option for canceling the paid-out of the ticket

5.1.b Paying-out a ticket is canceled

5.1.c The screen for paying-out is closed

Related information

Section 4. Special requirements



4.1 Business Requirements

Describe all business requirements for the software.

4.2 Functional Requirements

Customize this subfunction to contain the subfunctions necessary to comprehensively define the fundamental actions that must take place within the software to accept and process the inputs and to process and generate the outputs.

Subfunction templates for each of the means of specifying functional requirements are provided below.

3.2.xf Function X

When functional decomposition is used as the means of specifying the functional requirements provide a 3.2.xf subfunction for each function. Each 3.2.xf subfunction should be labeled and titled appropriately for a specific function, where xf is the appropriate sequential subfunction number and X is the name of the specific function.

3.2.xf.1 Function X Purpose

Describe the intent of the function.

3.2.xf.2 Function X Inputs

Describe the inputs to the function.

3.2.xf.3 Function X Operations

Describe the operations to be performed within the function.

3.2.xf.4 Function X Outputs

Describe the outputs from the function.



3.2.xu Use Case Y

When use cases are used as the means of specifying the functional requirements, provide a 3.2.xu subfunction for each use case. Each 3.2.xu subfunction should be labeled and titled appropriately for a specific use case, where xu is the appropriate sequential subfunction number and Y is the name of the specific use case.

Within each use case subfunction, specify the use case information, including the actor, pre-conditions, post-conditions, scenarios, and alternate scenarios.

3.3 Logical Data Requirements

Describe the logical data requirements for the software.

3.4 User Requirements

Describe the user requirements for the software.

3.5 Information Management Requirements

Describe the information management requirements for the software.

3.6 Systems Requirements

3.6.1 Performance Requirements

Describe the performance conditions and their associated capabilities.

3.6.2 Quality Requirements

Describe requirements for the quality characteristics of the software.

3.7 Interfaces

Describe the logical characteristics of each interface between the application and other hardware, software, and communication protocols.



3.8 Other Requirements

Identify any other requirements that do not fit appropriately into the preceding requirement sections.



Section 4. Requirements Traceability MatrixProvide reference to the location of the Requirements Traceability Matrix that indicates traceabilty from the system requirements documented in the System Requirements Specification to the design elements documented in the System Design Description to the software requirements documented in this Software Requirements Specification (SRS).



Section 5. ReferencesProvide a list of all documents and other sources of information referenced in the SRS and utilized in developing the SRS. Include for each the document number, title, date, and author.

Document No. Document Title Date Author



Section 6. GlossaryDefine of all terms and acronyms required to interpret the SRS properly.



Section 7. Revision HistoryIdentify changes to the SRS.

Version Date Name Description



Section 8. AppendicesInclude any relevant appendices.


Documents

biltenfvd