biltenfvd
-
Upload
bogdan-nicovski -
Category
Documents
-
view
215 -
download
3
description
Transcript of 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
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
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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.
Based onDIR Document 25SR-T1-0 Page 2
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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
Based onDIR Document 25SR-T1-0 Page 3
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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
Main success scenario
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
Based onDIR Document 25SR-T1-0 Page 4
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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
Main success scenario
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
Based onDIR Document 25SR-T1-0 Page 5
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
Pre conditionsIt must to have installed software on their computer, phone near dispatcher
Main success scenario
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
Main success scenario
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
Based onDIR Document 25SR-T1-0 Page 6
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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
Main success scenario
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
Based onDIR Document 25SR-T1-0 Page 7
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
started
4.2.b Information from the ticket are displayed, with the started matches marked with red color
Use case continue from step 2
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
Based onDIR Document 25SR-T1-0 Page 8
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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
Use case continue from step 2
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
Use case continue from step 2
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
Based onDIR Document 25SR-T1-0 Page 9
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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.
Based onDIR Document 25SR-T1-0 Page 10
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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.
Based onDIR Document 25SR-T1-0 Page 11
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
3.8 Other Requirements
Identify any other requirements that do not fit appropriately into the preceding requirement sections.
Based onDIR Document 25SR-T1-0 Page 12
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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).
Based onDIR Document 25SR-T1-0 Page 13
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
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
Based onDIR Document 25SR-T1-0 Page 14
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
Section 6. GlossaryDefine of all terms and acronyms required to interpret the SRS properly.
Based onDIR Document 25SR-T1-0 Page 15
Bransys SOFTWARE REQUIREMENTS SPECIFICATION FLEMAN [Version Number] | [Revision Date]
Section 7. Revision HistoryIdentify changes to the SRS.
Version Date Name Description
Based onDIR Document 25SR-T1-0 Page 16