0% found this document useful (0 votes)
696 views18 pages

FRD Sample Cab Management

This document provides functional requirements for a taxi booking application. It includes business rules, system rules, stakeholder requirements, assumptions and constraints. Key aspects summarized: 1. The application allows customers to book taxis, drivers to manage bookings and trips, and administrators to manage vendors, drivers and contracts. 2. Business rules cover requirements for drivers like filling petrol only at prescribed stations and having a license. System rules restrict database access and require supported operating systems. 3. Stakeholders include administrators, employees, and drivers. Each has different login and data access requirements. 4. Assumptions include vehicles and roles already being established, while constraints include background checks and limited database facilities. 5

Uploaded by

Kuldeep Rathod
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
696 views18 pages

FRD Sample Cab Management

This document provides functional requirements for a taxi booking application. It includes business rules, system rules, stakeholder requirements, assumptions and constraints. Key aspects summarized: 1. The application allows customers to book taxis, drivers to manage bookings and trips, and administrators to manage vendors, drivers and contracts. 2. Business rules cover requirements for drivers like filling petrol only at prescribed stations and having a license. System rules restrict database access and require supported operating systems. 3. Stakeholders include administrators, employees, and drivers. Each has different login and data access requirements. 4. Assumptions include vehicles and roles already being established, while constraints include background checks and limited database facilities. 5

Uploaded by

Kuldeep Rathod
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 18

FUNCTIONAL REQUIREMENT

DOCUMENT

Kuldeep
  
Document Version Control List

Version Date Author Description


01 FRD Doc

Distribution List

Version Date Name Role Distribution


Purpose
01 Senior BA Doc Owner
01 Project Manager Project Sponsor

Business Rules

1. The driver should Fill petrol only at prescribed stations.


2. Legal agreement with vendors.
3. Driver should have a License.
4. Payment settlement will be done by end of the month.
5. If passenger will not be on time, then driver will only wait for 5 minutes and start his ride.
6. All Drivers and passenger should use smartphones.

System Rules
1. Only Admin should have full access to internal data.
2. Database access should be restricted as per user workforce
3. Users should use Android or IOS Operating system in smartphones.
4. Search for taxi available if any booking comes.
5. Additional fare should be charged if user need to drop other then
prescribed location (driver side)
6. Timesheets to be filled up by driver on time and to be updated in system on daily basis.
Control Flow

Purpose
The functional requirements document (FRD) is a formal statement of an application's
functional requirements. It serves the same purpose as a contract. The developers
agree to provide the capabilities specified. The client agrees to find the product
satisfactory if it provides the capabilities specified in the FRD.

The Functional Requirements Document (FRD) has the following characteristics −


It demonstrates that the application provides value in terms of the business objectives and business
processes in the next few years.
It contains a complete set of requirements for the application. It leaves no room for anyone to
assume anything which is not stated in the FRD.
It is solution independent. The ERD is a statement of what the application is to do— not of how it
works. The FRD does not commit the developers to a design. For that reason, any reference to the
use of a specific technology is entirely inappropriate in an FRD.
Project Background

As the business is growing in demands with Customers, the former system is operated
in Excel Sheet where data is maintained via manual operation i.e add/del/edit of data
is done in manually which is troublesome.Also as more data is accumulating In
business the need of System upgrade is most in this time.The proposed system not only
solve above problems but also make ease of use to both customers and working staff
of company.
Current Problems:

1. Details are Stored Manually in papers, to share the details between employees was a
financial drawback.
2. .Updation of data in excel sheets is a tedious task

3. Performance is not achieved up to the requirements.

4. Manual errors have become big problem going beyond control of management.

5. Manipulation of data has become quite common within each sub vendor and drivers to
show bulged performance.

Project Objective
The Client needed a cab booking solution where employees can avail cab service at
after office hours at their convenience and prescribed place (usually office). the
solution focuses on use of cutting-edge technology software that delivers premium
professional service to client.
The client also needs to convert existing legacy database to software-based system
where operation of software is made ease to use.

Some details objectives include:


1.Vendor management is required by admin to keep track of all the vendors and sub vendors
who all are the part of star cabs like sub vendor for providing car and fuel vendors. System will
allow admin to keep all the agreements related to vendors at one place for proper
management.
2. Billing Management is centralized database for all the bill related activity where bills from
drivers and vendors can be accessed and updated without any manual intervention which will
lead to error free data and will leave no scope for manipulation of data.
4. Fuel Management to keep track on fuel consumption consumed.
5. GPS installation in Cars can help in getting the real time location of cab which will help in
assigning the cab which is nearest to the customer it also help in keeping track on actual distance
travelled by the cab which help in proper fuel management and accurate billing.
6. Vehicle Details management will give access to the staff to check the availability of the vehicle,
update vehicle details without any hassles.
7. Log sheet Management will enable drivers to directly upload the data related to trip rather than
manually entering and submitting to office.
8. Employee management will allow employee to access the system as per hierarchy.
9. MIS/ reports.

Business Requirements
1. Design staff friendly system.
2. Easy management of all the vendors.
3. Should be able to manage drivers
4. Check driver’s availability.
5. Allow to manage trips.
6. Handle all the cab bookings related things for the customers
7. If cab is not available should allow to book cab from sub vendors.
8. Show drivers rating.
9. Cancel trip booked by customers
10. Driver fills up petrol / diesel from register vendor.
11. Driver pick and drop clients at desired location.
12. Bill settlement should be done on every month end.
13. Maintain clients booking history log.
14. Reduce manual efforts by making application with good n required feature.
15. Satisfy customer by providing pleasant environment and an efficient service.
16. Generating revenues, building long-term customer relationship and spread good
word of mouth.
17. Keeping record of feedbacks received from the clients.
18. The client should get notification email of the booking while confirmed.
19. Client feedback form should be available.
Stake Holder Requirements

Stakeholder Requirements
Admin 1. Personal login,
2. Can add, edit & delete all data.
3. Can check for contracts with clients, cab
owners.
4. Admin will be processing with request
send by client for booking cabs from
searching cab till booking and generating
bill.
Employee 1. Personal Login
2.They can only view data accessible to
them.
3.Check reports of users

Driver 1.Personal Login


2. . Getting confirmation of trip through mail
only.
3.Acknowledgement to employee after
successful ride completation

Assumptions& Constraints
# List All Assumptions& Constraints Functional requirements are based on
Assumptions:
1. Vehicles are already purchased and available for use.
2. Roles and responsibilities are already established.
3. Drivers should fill correct timesheets and details.
4. Company has tie up with fuel stations.
5. company has contract with sub vendors.
6. verify sub vendor and drivers background before signing contract with them.

Constraints:

1. Background verification for drivers and subcontractors.


2. Payment settlement to be done on given period or late fees will be applicable.
3. This system will not support distributed database Facility.
4. Every employee should not have any rights to edit any data in the system.
5. System is limited to HTTP/HTTPS Protocols.
6. Smart phones should be based on android or IOS
7. Communications made through APP only.
8. MySQL Database Server.
Use Case Diagrams [UML]:

Actor Specific Use Case Diagrams


Use Case Specifications
[Use Case Specifications for each Use Case diagrams mentioned above]

Use Case ID : UC_1 Use Case Name:Client_UC


Created By : References :
1. Use Case Description How client book cab
2. Actor Passenger,driver,admin
3. Pre-Conditions Registration & signup
4. Basic Flow Step 1 :passenger opens APP
Step 2 :passenger books cab
Step 3 : Drivers gets notificaions
Step4: Driver picks and drops user.
5. Alternative Flow Step1: Driver may reject
Step2: customer may cancel trip
6. Exceptional Flow 1.technical smarphone problems.
2.network issues
7. Post –Conditions Successful trip send confirmation to employee.
8. Key Scenarios Vehicle should be registered, customer
agreement should be renewed on time.
9. Special Requirements Smartphones to both passenger and driver.
Acknowledgement after
successful/unsuccessfull trips.
Use Case ID : UC_2 Use Case Name: CMS Admin Perspective
Created By : References :
1. Use Case Description How admin responsibility in managing process

2. Actor Admin.
3. Pre-Conditions 1) system should have all required details.
2) Vehicle availability.
3) company should have contract with all
available cab vendor and sub vendor.
4) Detailed record of drivers.
5) Client Agreement.
6) Client Contract.
7) Amount per km for each client as rates
may vary for each client.
8) Contract with diesel vendors

4. Basic Flow Step1 : Add new vehicles in system.

Step2 : Admin should be able to search available


vehicle.

Step3 : Admin should upload vehicle document.

Step4 : Admin should add diesel vendor.

Step5 : Keep track of book number.

Step6 : Add clients in system.

Step7 : Search clients system.

Step8 : Upload client agreement in system.

Step9 : Add client rate in system.

Step10 : Upload client KM chart in required


format.

Step11 : Enter log sheet entry.

Step12 : Upload bulk log sheets.

Step13 : Enter diesel token entry.


Step14 : Enter penalty entry.

Step15 : Keep record of vehicle attendance.

Step16 : Keep drivers details.


5. Alternative Flow 1) If any new client is registered and cm rates
not available for that client then add client
rate first to system.
2) If driver not available for trip then arrange
another cab / driver.

6. Exceptional Flow If vendor not available then only sub vendor will
come in picture.
7. Post –Conditions Send trip confirmation mail to client
8. Key Scenarios
9. Special Requirements Excel format should be available to upload log
sheets.
Activity Diagram:
Process Specific Activity Diagrams
Activity Specification
Basic Flow Process Steps:
Step 1: Register user
Step 2: Login to system
Step 3: Add vehicle
Step 4: Add vehicle details
Step 5: Add owner details
Step 6: Add driver details
Step 7: Upload vehicle details
Step 8: Add Client
Step 9: Upload client agreement
Step 10: Upload client rate
Step 11: Client KM chart
Step 12: Search cab
Step 13: Enter pick & drop location
Step 14: Get Cab details
Step 15: Search cab by vehicle registration
number / driver name/owner name
Step 16: Confirm trip
Step 17: Driver will fill up log sheet details.
Step 18: Driver will fill up diesel book details in
sheet.
Step 19: Payment done by client every month
Step 20: Upload all details to system
Step 21: Logout

Alternative Flow Process Steps:


Step 1: If user not register then register him to
login into system.
Step 2: Search cab details will be done
w=either by vehicle registration number /
driver name/owner name
Step 3: Client not available then add client to
system
Step 4: If client rates not available then
add/upload client rates in system
Exception Flow Process Steps:
Step 1: Send mails on & from desired mail id.
Step 2: Show details on basis of permissions
Step 3: Upload files should be in proper format
if not data will be not be uploaded and show
error.
Functional Requirements
Functional Requirements are those the system needs to perform all those actions which
come in the development of the application are considered to be functional requirements.]
Requirements are prioritize as per below Standards
M-Must have S-Should have C- Could be in future W-Would like to

S.NO Req ID Description Priority


1 FR-BR 01_FR 01 Login functionality M
as per type of user
2 FR-BR 01_FR 02 All menus to be S
displayed on top
with its sub menus
3 FR-BR 01_FR 03 Add New Vehicle M
4 FR-BR 01_FR 04 Search Vehicle M
5 FR-BR 01_FR 05 Vehicle documents S
6 FR-BR 01_FR 06 Diesel vendor M
7 FR-BR 01_FR 07 Diesel book number S
8 FR-BR 01_FR 08 Logsheet book M
number
9 FR-BR 01_FR 09 Client master M
10 FR-BR 01_FR 10 Client agreement M
11 FR-BR 01_FR 11 Client rate S
12 FR-BR 01_FR 12 Client KM chart M

13 FR-BR 01_FR 13 Logsheet entry M


14 FR-BR 01_FR 14 Diesel token entry S
15 FR-BR 01_FR 15 Upload logsheet S
functionality
16 FR-BR 01_FR 16 Upload diesel token S
functionality
17 FR-BR 01_FR 17 Breadcrumb W
18 FR-BR 01_FR 18 Logout M

Non Functional Requirements


S.NO Req ID Description
1 NFR_Domain_ID_0 Scalability Requirements - Should have potential to grow
1 in time to efficiently handle multiple request per minute
2. NFR_Domain_ID_0 Security Requirements -
2 1) Network and data security
2) Data validation and sanitization
3) Authentication and password management
4) Authorization and role management
3. NFR_Domain_ID_0 Availability Requirements –
3 1) Back end internal computers
2) Internet service provider
Prototyping

You might also like