Politecnico di Torino

TOP - UIC

Car Sharing System

Requirements Specification

C. Cogrossi, A. Del Giudice, R. Martini, G. Pioppo

January 14, 2005

 Contents

1 User Requirements 3
1.1 Project Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 The purpose of the project . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Client, Customer and other Stakeholders . . . . . . . . . . . . . 3
1.1.3 Users of the product . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Project Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Mandated constraints . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Relevant Facts and Assumptions . . . . . . . . . . . . . . . . . 7
1.3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Scope of the Work . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 The scope of the product . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Functional and data Requirements . . . . . . . . . . . . . . . . 15
1.3.4 Inverse Requirements . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1 Look and Feel Requirements . . . . . . . . . . . . . . . . . . . . 18
1.4.2 Performance Requirements . . . . . . . . . . . . . . . . . . . . . 19
1.4.3 Operational Requirements . . . . . . . . . . . . . . . . . . . . . 20
1.4.4 Maintainability and Support Requirements . . . . . . . . . . . . 20
1.4.5 Security requirements . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Project Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5.1 Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.5.2 Off-the-Shelf Solutions . . . . . . . . . . . . . . . . . . . . . . . 23
1.6 New problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.7 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.7.1 User Documentation and Training . . . . . . . . . . . . . . . . . 24

2 Developer Requirements 26
2.1 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Data-dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 UML Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1 Sequence diagram for Use Case Making Reservation . . . . . . . 31

1
 2.3.2 Sequence diagram for Use Case Modify Reservation . . . . . . . 32
2.3.3 Sequence diagram for Use Case Delete Reservation . . . . . . . 33
2.3.4 Sequence diagram for Use Case Upload car data . . . . . . . . . 34
2.3.5 Sequence diagram for Use Case Upload Vehicle Position . . . . . 35
2.3.6 Sequence diagram for Use Case Communicate Order . . . . . . . 35
2.3.7 Sequence diagram for Use Case Data Handling . . . . . . . . . . 36
2.3.8 Sequence diagram for Use Case Payment Handling . . . . . . . 36
2.4 Traceability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2
 CHAPTER 1

User Requirements

1.1 Project Drivers

1.1.1 The purpose of the project
TUGO company (from now on the contractor) asked us to develop a software system
in order to manage a fleet of vehicles in the context of a carsharing system in a non
better precised western medium-sized city (approx 1M inhabitants). In order to face up
the never-ending increasing of private vehicle congestion in urban areas, a car sharing
system is considered as one of the possible solutions to this issue. Our software is
the main control system of the fleet of vehicles, the personnel involved and the set of
users. Its mission is to avoid any problematic issue might damage people, users and the
contractor. On the other hand it should increase the contractor’s profits by managing
the vehicles’ fleet and personnel in the most suitable way.

1.1.2 Client, Customer and other Stakeholders

The client is TUGO, a company located in Turin, which decided to deploy a urban
carsharing service. This entity is personified by Mr. Morisio and every user requirement
issue shall be discussed with him. The customer is TUGO itself or, more precisely, the
carsharing division of the company. Other stakeholders1 are - Control center employees
- Legal Expert - System Designer

1.1.3 Users of the product

Final users are classified in the following:
1
A stakeholder is a person or organisation who has some demand on the product and/or is affected
by its outcome/success.

3
 Category Tech experience Subject matter Priority
experience
Internet positive journeyman or more any key user
attitude people
Elder people novice novice unimportant user
Other calling people journeyman or more journeyman or more secondary user
Call center operator journeyman journeyman secondary user
Control center operator master master key user

Table 1.1: Users of the product

1. Internet positive attitude people: people who like technology and trust it,
they will probably be at ease with the web interface; they are supposed to be the
main percentage among final customers (key user).

2. Elder people : people who feel unease with technologies, probably elder men/women.
They do not like the web interface and would rather use the call center. They
are supposed to be a minor percentage among the final customer. The call center
has been conceived for them (unimportant user).

3. Control Center operator : people working at the control center, they must be
taught properly to interact with the system. They must be in the lower possible
number in order not to increase human resources cost (Probably they will be
fairly people)(key user).

4. Moped man: people working on the road. They are charged of the dislocation
of the vehicle among the parking lots to fit reservation criterion. They must be
taught the use of PDA devices (key user).

5. Call center operator: people working at call center (probably ad interim work-
ers). They must be able to use the web interface. They role is mainly to take
elder people call and make reservation for them or to make quick operations for
people who can’t access the web (secondary user).

6. Other calling people: people who momentaneously can not access the web
and are oblige to contact the call center by phone. They are supposed to know
exactly what they want. They need a call operator only because they can not
access the web interface directly.

For sake of simplicity all users and related information are reported on table 1.1.

4
1.2 Project Constraints
1.2.1 Mandated constraints
In order to get an acceptable solution it is necessary to follow the solution design
constraints listed in table 1.2.

Type Description
SDC-1 The product must use a system to get data from vehicles
SDC-2 The product must use a GPS to get the position of vehicles
SDC-3 The system must use an open-source solution
SDC-4 The product must use handheld devices to communicate with the moped men
SDC-5 The system must use a web-interface
SDC-6 The product must use precharged cards to make fuel operations
SDC-7 The complexity must lie on the system and not on human resources

Table 1.2: Solution design constraints

The system, including automated, mechanical, organizational and possibly other

devices, will be installed in the same building. From the technological point of view,
a Virtual Private Network will be realised for the connection of the servers; in figure
1.1 the structure of the system is shown. The bank application is the only one that
has to be taken into account even though it is not part of the UGA system. Bank
manages the car-rent and the fuel-operations payments. To do that the bank uses
its own application and then it communicates data through the bank portal. That
information will be stored in a buffer in order to not directly modify UGO; it may
cause troubles in the system that way.
There is one application related to SDC-4, it is the Routing Application. Moped men
have a handheld device in order to receive commands from the system. The Routing
Application indicates them what is the fastest path to reach the place indicated by
UGO.
The product will be used in different places(see table 1.3).

Number Place
1 Control Center
2 Call Center
3 Home or Internet point
4 Outside

Table 1.3: Workplaces

Number 2 and 3 are places from which the user can make a reservation. Number 4
includes moped men who communicate with the system through the handheld devices

5
 Figure 1.1: Tecnical environment.

and the reservation boxes. Let’s describe more precisely the workplace (see table 1.4).

Number Description
1,2,3 The workplace is in a building
4 The product must be waterproof
4 The product has displays that are visible in sunlight
4 The workplace can be noisy, so audible signals might not be heard

Table 1.4: Description of the workplace

The deadline for the requirement documentation is January fourth. It is important

to deliver the product for this date because other parts of the business or other software
products are dependent on this. If the product is delivered late this will have a big
financial impact. Because of the postponing of the activities, the cost of the project
could increase considerably.
There are not constraints about the budget, so we have complete freedom to design
the product.

6
1.2.2 Relevant Facts and Assumptions
UGO is developed to handle the management of a relatively big car-sharing system, as
the city where it will be implemented has around 1M inhabitants. UGO shall not be a
limit to the potential future growth of the car-sharing system: it must be suited to deal
properly with a much larger quantity of users and vehicles (essentially their ”data”)
than the one that the contractor expects for the first months after the launch of his
system. Since there is no previous system UGO shall be correctly working by the day
it is effectively implemented. On the other hand, as the criticality level of the system
is not high there is no redundancy: only back-up of reservations and users data is
performed. In the unlikely case of crash of the system UGO is simply restarted by the
control centre. The contractor provides all the hardware devices that will allow UGO
to work (e.g.: servers), as he has an agreement with the XXX supplier company. The
system has to be designed taking into account the possible advantages and drawbacks
deriving from this choice. Regarding the software ”environment” our philosophy is
oriented to an open source solution. For mapping and routing issues XXX from YYY
will be used and since this product has been on the market for a considerable time and
it has been widely used in similar application, then its reliability is highly verified.

7
1.3 Functional Requirements
1.3.1 Scope of the Work
There are several example of Car Sharing around the world, mainly in Germany and in
North-America (meaning USA and Canada). Almost all systems do not allow people
to leave the car in a different position because otherwise it would be too difficult to
manage the displacement of the cars among the different parking lots in the city. UGO
is more evolved and it was born with the purpose to manage displacement of cars in
order to grant a better service to the final user. This new requirement introduces new
human character: the moped-man. The system, thus, has also to handle the position
of those staff members and communicate them the position of the car that need to be
moved or simply need assistance.
In figure 1.2 is shown the context diagram. All the agents of the system communi-
cate via a portal.
User can made reservation operation from the web, from the box near the parking
lots(where installed) and by call center. Both those operations are made by the same
portal, in fact call center operators are used only for older people who do not love the
web and prefer human contact, so they act on the same web interface via the same
portal (user portal).
Also car and moped-man transmit similar data, so they act on the same portal
(vehicle portal)
In the table 1.3.3 are listed all business events involving Ugo. From these we can
define requirement types. We remark that user is meant as both the final driver or the
call center operator. These two profiles can be merged because they access the system
via the same portal.

Type Event name Input Output Portal

1 User makes a reservation new reservation (in) reservation
2 User deletes a reservation del reservation (in) reservation
3 User modifies a reservation change reservation (in) reservation
4 Vehicle communicates position position update (in) vehicle
5 Car communicates data data update (in) vehicle
6 Moped-man gets orders communicate (out) vehicle
7 Control center checks the situation check situation (out) control
8 Control center defines parking lot set add parking (in) control
9 Control center menages cars add car (in) control
10 Control center modifies fees fees (in) control
11 Bank communicates payments bill (in) bank

Table 1.5: Business event list

8
 Figure 1.2: Context diagram for UGO.

1.3.2 The scope of the product

Use cases typically depict interactions between external actors and the system from
the point of view of the user. The interaction among actors and the system starts with
initial events triggered by the actor on the system and ends when the logical reaction
of the system has finished. The UGO’s use case diagram is shown in figure 2.12.
In table 2.12 we list all use cases with the correspondent actor and scenarios where
they are described.
The scenarios in table 1.7 describe the system in common situations.

9
 Figure 1.3: UGO use case diagram.

Use case Actors Scenarios

Making reservation user 1,2
Modify reservation user 3,4
Delete reservation user 5
Upload car data car 6,7
Upload vehicle position car, moped men 8
Data handling DB 10
Communicate order moped men 9
Payment handling control center, bank 11

Table 1.6: Use case list

10
 Scenario 1
Scenario for use case make-reservation.User makes a web reservation:
sets time parameters, car model and locations. The reservation is ac-
cepted.
1 User selects reservation icon on the web page
2 User enters iserID
3 User sets pick-up time → 4/1/04 ;14:00 fur-1
4 User sets dropOutTime→ 4/1/04;18:00 fur-1
5 User sets car type → A fur-2
6 User sets pick-up location → Via Roma fur-3
7 User sets release location → Via Roma fur-3
8 The system accepts this as a valid reservation fur-18
9 use case data-handling fur-3
10 The system sends back a confirm message fur-30
with the code of the reservation
Scenario 2
Scenario for use case make-reservation. User makes a web reservation:
sets time parameters, car model and locations. The reservation is not
accepted.
1 User select reservation icon on the web page
2 User enters iserID
3 User sets pick-up time → 4/1/04 ;14:00 fur-1
4 User sets dropOutTime→ 4/1/04;18:00 fur-1
5 User sets car type → A fur-2
6 User sets pick-up location → Via Roma fur-3
7 User sets release location → Via Roma fur-3
8 The system cannot find available cars at the requested time fur-16
9 The system proposes an alternative solution pick-up time → fur-3
4/1/04;15:00
10 User cancels his reservation fur-4
Scenario 3
Scenario for use case modify-reservation. User has a web modification
procedure: changes the release location. The reservation change is ac-
cepted.
1 User select modify-reservation icon on the web page
2 User enters userID
3 User enters the reservationID
continued on the next page

11
 continued from the previous page
4 User changes dropOutLocation from → Via Roma to → P.za fur-6
Solferino
5 The system accepts this as a valid change and updates the reserva- fur-18
tion
6 → use case data-handling
7 The system sends back a confirm message with the code of the fur-30
reservation
Scenario 4
Scenario for use case modify-reservation. User has a web modification
procedure: changes the pick-up location. The new location is not avail-
able. The user selects the alternative one.
1 User select modify-reservation icon on the web page
2 User enters userID
3 User enters the reservationID
4 User changes pickupLocation from → Via Roma to → P.za Solferino fur-6
5 The system cannot accept this change fur-18
6 The system proposes an alternative solution pickupLocation → P.za fur-16
Castello and ask for new inputs
and asks for new inputs
7 The user decides to update the reservation with the alternative fur-6
location
8 The system updates the reservation fur-18
9 → use case data-handling
10 The system sends back a confirm message with the reservationID fur-30
Scenario 5
Scenario for use case delete-reservation. User has a voice delete pro-
cedure: the reservation was intended to start after 3h only. The user
deletes the reservation. Another user books in the same time span. The
user is not charged for anything.
1 User phones to the call-centre
2 The operator starts the delete procedure (same interface as in a fur-4
web procedure)
3 The system warns that it is too late for a regular deletion (3h inverse
instead of 6h)
4 The user decides to delete his reservation anyway fur-4
5 The operator gives input to delete the reservation
6 The system maintains the reservation as assignable to another user fur-18
continued on the next page

12
 continued from the previous page
7 → use case data-handling
8 Within the 3 hours another user makes a reservation in the same
time span
9 The system deletes completely the reservation of the first user fur-18
10 use case data-handling
11 The system sends a message that no bill will be charged to the first fur-30
user
Scenario 6
Scenario for use case upload-car-data. A car that has been refuelled
sends is data. A credit is assigned to the user.
1 A car sends all its parameters fur-10,
fur-13
2 The system loads the data fur-29
3 The system detects that the refueling has been performed fur-16
4 The refuelling was not strictly requested
5 The system assigns a credit to the user fur-19
6 use case data-handling
Scenario 7
Scenario for use case upload-car-data. One user is late and another one
waits for his car. The car is to far from the release(pick-up) location.
No other car is available. A taxi is called for the second user. The fist
user will pay the bill.
1 A user informs the call centre that his car is not in the location and
the operator starts the procedure for the delay cases
2 The car is continuously transmitting his position fur-8
3 The system checks the car position fur-29
4 The system sends a warning to the user who is late fur-30
5 The car is too far from the DropOut/pickUpLocation fur-16
6 The system checks if other cars are available fur-16
7 Since there is no other car, the system request to the operator to fur-31
call a taxi for the user who is waiting
8 The taxi bill will be charged to the user who is late fur-19
9 The reservation of the user waiting is deleted fur-4
10 → use case data-handling
Scenario 8
Scenario for use case upload-vehicle-position. A parked car needs refu-
elling. The system searches for the nearest moped man to charge him
of the operation.
continued on the next page

13
 continued from the previous page
1 The system has checked cars data and finds a parked car that needs fur-16
refueling
2 Moped are continuously transmitting their position fur-9
3 The system uploads the position of all the moped men fur-29
4 The system finds the nearest one that is not performing any oper- fur-16
ation (idle)
5 use case communicate-order
Scenario 9
Scenario for use case communicate-orders. A moped man has to refuel
a car. The system sends him an order to perform the operation. The
moped man refuels the car.
1 A car needs refueling and the nearest moped man has been found
2 The system sends a message to the moped man that this operation fur-14
has to be performed with location and car ID
3 The system marks the moped man as busy with a mission fur-16
4 The system loads car data fur-10
fur-13
5 → use case load car data
6 The system detects a refueling fur-16
7 The system records the fueling operation fur-19
8 → use case data-handling
9 The system marks the motorbike man as Mission:idle fur-16
Scenario 10
Scenario for use case data-handling. A credit for fuelling is stored in the
database.
1 The system has found out that a not requested refuelling has been fur-16
performed
2 The system uploads the record of the user in the database assigning fur-19
a credit
Scenario 11
Scenario for use case payment-handling. The bank sends all the fuel
payments of the week/month. One payment is missing. An operator is
charged to verify with the bank.
1 The system receives the records of the fuel payments from the bank fur-27
2 The system checks the notifications against the record of performed fur-19
fuel operations
continued on the next page

14
 continued from the previous page
3 The system marks as paid the corresponding fuel operations fur-19
4 The system founds that all the payment notifications are correct fur-19
5 The system records all the payment notifications fur-19
6 One payment is still missing
7 The system sends a message to an operator of the call-centre to call
the bank and verify if there is any mistake

Table 1.7: Scenarios

1.3.3 Functional and data Requirements

In the table 1.3.3 are listed all business events involving Ugo. From these we can
define requirement types. We remark that user is meant as both the final driver or the
call center operator. These two profiles can be merged because2 they access the system
via the same portal.

Type Event name Input Output Portal

1 User makes a reservation new booking (in) booking
2 User deletes a booking del booking (in) booking
3 User modifies a booking change booking (in) booking
4 Vehicle communicates position position update (in) vehicle
5 Car communicates data data update (in) vehicle
6 Moped men gets orders communicate (out) vehicle
7 Control center checks the situation check situation (out) control
8 Control center defines parking lot set add parking (in) control
9 Control center menages cars add car (in) control
10 Control center modifies fees fees (in) control
11 Bank communicates payments bill (in) bank

Table 1.8: Business event list

2
We define as time parameters hour and date XXXX and time span

15
Requirement Type Description
fur1 1 User can schedule time parameters4
fur 2 1 User can choose a car model
fur 3 1 User can select pick-up and release location
fur 4 2 User can delete a reservation
fur 5 3 User can change time parameters
fur 6 3 User can change pick-up and release location
fur 7 3 User can change a car model
fur 8 4 Car communicates its position continuously
fur 9 4 Moped men communicates their position continuously
fur10 5 Car communicates mileage continuously
fur11 5 Car communicates fuel level continuously
fur12 5 Car communicates misfunctions
fur13 5 Car communicates assistance request
fur14 6 System communicates position and needs of a car to moped men
fur15 6 System communicates car displacement request to moped men
fur16 7 Control center is able to check on a map vehicles’ position and data
fur17 7 Control center is able to check personal details
fur18 7 Control center is able to check reservation data
fur19 7 Control center is able to check payment situations
fur20 7 Control center is able to check personal details
fur21 8 Control center can add new parking lots
fur22 8 Control center can remove new parking lots
fur23 9 Control center can add cars
fur24 9 Control center can remove cars
fur25 9 Control center can modify cars
fur26 10 Control center can modify fees
fur27 11 Bank communicates fuel payments
fur28 11 Bank communicates user payments
fur29 5 System is able to receive vehicles data and position
fur30 5 System is able to communicate with users (e.g.:sms)

Table 1.9: User functional requirements

16
1.3.4 Inverse Requirements
Requirement Description
ir1 User is not allowed to change or delete reservation 6h before the
date
ir2 The system must not allocate the same car for two reservations.
ir3 If the electricity current stops, all the data do not be lost.
ir4 If the load increases more than the forecast number of user the
system does not shout down.
ir5 Bank payement application must not modify or have access to the
system data.

Table 1.10: Inverse user requirements

17
1.4 Non-Functional Requirements
1.4.1 Look and Feel Requirements
Table 1.11 contains requirements including the user’s demands on how the interface
has to look like in order to ensure that the appearance of the product conforms to the
organization’s expectations.

Type Description
LAF-1 The product shall comply with corporate branding standards
LAF-2 The product shall be attractive to an adult audience
LAF-3 The product shall be user-friendly
LAF-4 The product shall appear authoritative
LAF-5 The product shall inspire confidence

Table 1.11: Look and feel requirements

The product will be used from different users. Table 1.12 contains usability and hu-
manity requirements. They are divided into different categories. To be more complete,
we first describe every group of specifications:

• Ease to use: requirements concerning the usability and the humanity of the
product. They are important in order to guide the product’s designers into
building a product that will meet the expectations of its eventual users.

• Personalization and internationalization: describe the way the product can

be altered or configured to take into account the user’s personal preferences or
choice of language.

• Ease of learning: how easy it should be to learn to use the product in order to
quantify the amount of time that your client feels is allowable before a user can
successfully use the product.

• Understandability and Politeness: related to concepts and metaphors that

are familiar to the intended end-users in order to make the product more com-
prehensible and thus more likely to be adopted by its intended users.

• Accessibility: how easy it should be for people with common disabilities to

access the product.

We remember that UGO shall be used by different people. Some of them, such as
the control center people, must be qualified and well trained, others, such as the users
who make a reservation, have to have the possibility to use the product without any
training or particular knowledge.

18
 Type Description
Ease to use
UAH-1 The product could be used by people with no training
UAH-2 The product shall help the user to avoid making mistakes
UAH-3 The product shall be used by people no understanding Italian and English
UAH-4 The product shall make the users want to use it
UAH-5 The product shall be easy to use
Personalization and internationalization
UAH-6 The product shall retain the buyer’s buying preferences
UAH-7 The product shall allow the user to select a chosen language
UAH-8 The product shall allow the user to convert the price into his currency
UAH-9 The product shall allow the users to set his measure convention
Ease of learnig
UAH-10 The reservation interface shall be easy for everyone to learn
UAH-11 The order interface shall be used by people who will receive no training
UAH-12 The product shall be easy for an engineer to learn
Understandability and Politeness
UAH-13 The product shall hide the details of its construction from the user
UAH-14 The product shall use symbols that are understandable by the user
Accessibility
UAH-15 The product shall be usable by sight-challenged users

Table 1.12: Usability and Humanity Requirements

1.4.2 Performance Requirements

Performance requirements can be divided into different categories that are described
below. The list of specifications is in table 1.13.

• Speed and latency: specification the amount of time available to complete

specified tasks. UGO is a real-time product and it must be able to perform some
of its functionality within a given time slot.

• Precision or accuracy: quantification of the desired accuracy of the results

produced by the product.

• Reliability and Availability: quantification of the necessary reliability of the

product in order to explore the possibility of failure and to specify realistic levels
of service.

• Robustness or fault tolerance: specification of the ability of the product to

continue to function under abnormal circumstances.

19
 • Capacity: specification of the volumes that the product must be able to deal
with and the numbers of data stored by the product.

• Scalability or extensibility:specification of the expected increases in size that

the product must be able to handle.

• Longevity: expected lifetime of the product.

1.4.3 Operational Requirements

In section 4, we have already described the physical environment in which the product
will work. Now, we want to highlight conditions that might need special requirements,
preparations or training. These requirements ensure that the product is fit to be used
in its intended environment. They are listed in table 1.14. The new system will be
composed by different servers. Some of them receive data from the moped men, the
bank and from the on-board unit and the main one called the webserver receives and
elaborates reservation data from the call center, the box, the user and data from other
servers through the VPN.
The product will interface with the bank application which controls the payment
operations. This application can not modify UGO. It will put the information in a
buffer that will be saved in a data base and will be controlled by the control center.
The product will be installed directly on the servers by the software enterprise.

1.4.4 Maintainability and Support Requirements

It is possible that, during its lifetime, the product needs some changes. They can take
some time, it depends on the kind and the complexity of the operation.
The maintenance or help releases will be offered, in case counseling agreement is
reach. The user can contact us for help via telephone number or via e-mail. The
product is self-supporting.
It is expected that the product will run on Linux for what concerns the servers.
It is possible that on the call center computers the product will run on Windows XP.
Moreover, the product is expected to run in offices and outdoor.
The installation will take a couple of working days.

1.4.5 Security requirements

Each customer (intended as car sharer) has his own id and password. He can access
the system via web with id and password or through call center giving its coordinates
(no pass required by operators).
Each call center operator has his own id and password. He can access directly to
the web interface. For any customer, each operation he make is recorded.

20
 Type Description
Speed and latency
PR-1 The response shall be fast to avoid interrupting the user’s flow of thought
PR-2 The product shall receive and elaborate vehicles position data every second
PR-3 The product shall receive and elaborate vehicles data every five minutes
PR-4 The product shall upload the global situation every minute
Precision or accuracy
PR-5 All monetary amounts shall be accurate to 2 digits
PR-6 Accuracy of fuel level readings shall be within + or - 3 deciliters
PR-7 Accuracy of oil level readings shall be within + or - 1 deciliter
PR-8 Accuracy of position readings shall be within + or - 1 meter
Reliability and Availability
PR-9 The product shall be available for use 24 hours per day, 365 days per year
PR-10 The product shall achieve 99% up time
Robustness or fault tolerance
PR-11 product shall continue to operate in local mode whenever it loses
its link to the central server.
PR-12 The product shall provide 10 minutes of emergency operation should
it become disconnected from the electricity source
PR-13 The product shall estimate the vehicle position whenever it does
no longer receive data
PR-14 The product shall estimate data vehicle whenever it does no longer
receive them
Capacity
PR-15 The product shall cater for 60 simultaneous users
PR-16 The product shall cater for the continuous data flow
Scalability or extensibility
PR-17 The product shall be capable of processing the existing 1000 customers.
This number is expected to grow to 5000 within three years.
Longevity
PR-18 The product shall be expected to operate within the maximum maintenance
budget for a minimum of 5 years

Table 1.13: Performance Requirements

Each control center operator has his own id and password. He can access directly
to the database via some interface. He can check each user id. Their authentication
must be safe (maybe with kerberos or stuff like that).

21
Type Description
per-1 The product shall be used by a worker in a office
per-2 The product shall be used by a worker, standing up, outside in cold,
rainy conditions
per-3 The product shall be able to run on a palmar device

Table 1.14: Expected physical environment

22
1.5 Project Issues
1.5.1 Open Issues
At the beginning of our partnership with the contractor, he assyred that to implement
the UGO system all hardware will be provided by the company XXX, and gave as
specifications about the models that will be used. The characteristics of the available
hardware could influence some design choices. Since we do not have direct contact with
the suppliers, we cannot be sure that at the moment of the effective implementation of
the system the initial conditions will have remained the same. Anyway the contractor’s
guarantee reduces the risks connected to the hardware supply.

1.5.2 Off-the-Shelf Solutions

The product YYY from ZZZ will be bought for mapping and routing. Alternatively
other similar ready-made products are available on the market. This one is widely used
by a considerable time so the doubt about reliability is minimal. Since our company is
just born we don’t have any component that could be reused from previously developed
systems. As well this is one of the first ”highly-automated” car-sharing management
system to be developed, then there are not ready-made solution that could be copied.
But concerning the database and the payment management in many other different
system it will be possible to find usable components to be adapted to our solution
(differences in the hardware should be considered for example) thus possibly reducing
the effort and time.

1.6 New problems

UGO is a new application. So, there will not be problems with the existing environment
or users. The application has been projected in order to not shut down completely if
the electricity power stops. Some devices has been introduced to let the call center
operators to save all the information before the termination of the operations.
UGO will have to coexist with the existing bank payment program. The latter
will inform the product about people payment situation. There must not be conflicts
between the two application in order to have the right behavior of UGO. UGO sees
the information the bank send and it cannot be modified by the bank.
UGO has been projected in order to cope with the forecast of amount of people
who will use the car sharing system. In the future if the amount will grow it will be
possible to power the existing system or substitute some parts of it.

23
1.7 Risks
In every project there are some risks. These risks can become problems if we do not
consider them. Otherwise, if we are aware of them we will know what to do if they
occur. In table 1.7 there is the list of the principle risks can occur in UGO application.

Nr Description
1 Excessive schedule pressure
2 Inaccurate cost estimating
3 Inaccurate amount of users estimating
4 Erroneous productivity estimating
5 Undervaluation of human skills

Table 1.15: Risks

1.7.1 User Documentation and Training

With the final system will be release documentation for customers (only regarding web
interface), call center operator and control center crew. Also human training must not
be undervalued.
Web interface documentation
The purpose of this document is to describe how to use web interface. It must be
preferably a short electronic document (something like a PDF) that could be easily
printed on leaflet or brochures. In that way documentation will be diffuse easily both
via web and in info center. It does not need to be long, because otherwise it would
disorientate readers. It is better a brief and simple document.
Call center documentation
The purpose of this document is to describe how to use web interface at call center.
Basically web interface is the same as for user, so the documentation will be almost
the same.
Control Center documentation
The purpose of this document is to describe the use of control center interface.
Control center operator functions are mission critical, so this documentation must
be complete and detailed. It must be a good guide to solve any kind of doubt that
may occurs to operators, do not forget that control center operator must be taught
to the functioning of the system, because they are charged of sensible operation like
programming tariffs plans.
Training
Call center operators do not need to be trained in any way. Call center web interface
documentation it is suppose to be sufficient to the scope. On the contrary Control

24
center operator must be taught to the function the system provides. They must know
how the system works and must be able to individuate malfunctioning in case, they
will be charged to call a technician in case of necessity.

25
 CHAPTER 2

Developer Requirements

Here follow UML diagrams to describe requirements. This comprehends a class diagram
with DataDictionary, Sequence, COLLABORATION DIAGRAM.

2.1 Class diagram

The UGO’s class diagram is described in figure 2.1.

Figure 2.1: Class diagram.

26
2.2 Data-dictionary
Into the data-dictionary are described all the classes together with their attributes,
methods and relationships.

Object to be Attributes, Methods Description

described
Car assistanceDetails If any,contains details of as-
sistance request
position GPS position in GPS coor-
dinates
misfunctions details of misfunctions
location logic position
carID car ID
mileage absolute mileage in km
fuelLevel fuel level in liters
communicatePosition() communicates GPS position
to control center
communicateLocation() communicates logic position
to control center
communicateMisfunction() communicates misfunctions
to control center
communicateAssistanceRequest() communicates GPS position
to control center
communicateMileage() communicates absolute
mileage in km
communicateFuelLevel() communicates fuel level in
liters
communicateCarID() communicates car ID
modifyPosition() modifies position
modifyLocation() modifies location
modifyFuelLevel() modifies fuelLevel
modifyMisfunctions() modifies misfunctions
modifyAssistanceDetails() modifies AssitanceDetails
ParkingLot parkingLotID parking lot ID
location logic location correspondent
to parking lot
continued on the next page

27
 continued from the previous page
state shows whether is free, taken
or out of order
communicateParkingLotID() communicates parking lot
ID
communicateState() communicates parking lot
state
Bank communicateFuelPayments() communicates fuel pay-
ments details
communicateUserPayments() communicates user pay-
ments details
User userID userID
personalData user personal data
paymentDetails user payment details
makeReservation() make a new reservation
providing all information
needed
deleteReservation() deletes a reservation of
user’s
modifyReservation() modify a reservation of
user’s
communicateUserID() communicates user ID
modifyPersonalData() modifies user personal data
modifyPaymentDetails() modifies payment details
Motorbike motorbikeID motorbike ID
position GPS position in GPS coor-
dinates
location logic position
missionDetails mission details of motorbike
communicateMotorbikeID() communicates motorbike ID
communicatePosition() communicates motorbike
position
communicateLocation() communicates motorbike lo-
cation
modifyMissionDetails() modifies mission details
ControlCenter map the whole area map
users users
reservations the whole set of reservations
continued on the next page

28
 continued from the previous page
parkingLots the whole set of parking lots
cars the whole set of cars
motorbikes the whole set of motorbikes
fees applicable fees
assistanceRequest() communicates an assistance
request
displacementRequest() communicates an displace-
ment request
showMap() shows the map
checkUserDetails() checks user details
checkReservationDetails() checks reservation details
checkPaymentDetails() checks payment details
addParkingLot() add one item to the parking
lot set
removeParkingLot() remove one item to the
parking lot set
addCar() add one item to the car set
modifyCar() modify one item in the car
set
removeCar() removes one item to the car
set
modifyFees() modifies applicable fees
SendUserAMessage() sent a message to the user
loadVehicleData() load vehicle data
checkVehicleData() check vehicle data
checkVehiclePosition() check where is the car
checkAvailableCars() check available cars
ExternalCall()
fuelRecordManagement()
PaymentRecordManagement()
Reservation reservationID reservation ID
pickUpTime time when car will be picked
up
dropOutTime time when car will be drop
out
pickUpLocation location where car will be
picked up
continued on the next page

29
 continued from the previous page
dropOutLocation location where car will be
drop out
carType model of car requested
AssistanceDetails details relative to requested
assistance
Misfunctions type of misfunction
GPSPosition GPS coordinates
PersonalData whole set of personal data
PaymentDetails whole set of payment details
Location logical location
CarType model of car
Time time (dd/mm/yy hh:mm)
Fees fees
Map map structure
Mission mission details
Status status
communicateReservationID() communicates reservation
ID
recordReservation() record the reservation
modifyPickUpTime() modifies pick up time
modifyDropOutTime() modifies drop out time
modifyPickUpLocation() modifies pick up location
modifyDropOutLocation() modifies drop out location
modifyCarType() modifies model of car re-
quested

Table 2.1: Data dictionary

30
2.3 UML Sequence Diagrams
Use Cases of this system are detailed below with sequence diagrams.

2.3.1 Sequence diagram for Use Case Making Reservation

Figure 2.2: Sequence diagram for scenario 1.

31
 Figure 2.3: Sequence diagram for scenario 2.

2.3.2 Sequence diagram for Use Case Modify Reservation

Figure 2.4: Sequence diagram for scenario 3.

32
 Figure 2.5: Sequence diagram for scenario 4.

2.3.3 Sequence diagram for Use Case Delete Reservation

Figure 2.6: Sequence diagram for scenario 5.

33
2.3.4 Sequence diagram for Use Case Upload car data

Figure 2.7: Sequence diagram for scenario 6.

Figure 2.8: Sequence diagram for scenario 7.

34
2.3.5 Sequence diagram for Use Case Upload Vehicle Position

Figure 2.9: Sequence diagram for scenario 8.

2.3.6 Sequence diagram for Use Case Communicate Order

Figure 2.10: Sequence diagram for scenario 9.

35
2.3.7 Sequence diagram for Use Case Data Handling

Figure 2.11: Sequence diagram for scenario 10.

2.3.8 Sequence diagram for Use Case Payment Handling

Figure 2.12: Sequence diagram for scenario 11.

36
2.4 Traceability Matrix
In the traceability matrix will be depicted in which classes have been mapped user
requirements. (Table 2.2)

Table 2.2: Traceability matrix

37
 List of Figures

1.1 Tecnical environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Context diagram for UGO. . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 UGO use case diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Class diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Sequence diagram for scenario 1. . . . . . . . . . . . . . . . . . . . . . 31
2.3 Sequence diagram for scenario 2. . . . . . . . . . . . . . . . . . . . . . 32
2.4 Sequence diagram for scenario 3. . . . . . . . . . . . . . . . . . . . . . 32
2.5 Sequence diagram for scenario 4. . . . . . . . . . . . . . . . . . . . . . 33
2.6 Sequence diagram for scenario 5. . . . . . . . . . . . . . . . . . . . . . 33
2.7 Sequence diagram for scenario 6. . . . . . . . . . . . . . . . . . . . . . 34
2.8 Sequence diagram for scenario 7. . . . . . . . . . . . . . . . . . . . . . 34
2.9 Sequence diagram for scenario 8. . . . . . . . . . . . . . . . . . . . . . 35
2.10 Sequence diagram for scenario 9. . . . . . . . . . . . . . . . . . . . . . 35
2.11 Sequence diagram for scenario 10. . . . . . . . . . . . . . . . . . . . . . 36
2.12 Sequence diagram for scenario 11. . . . . . . . . . . . . . . . . . . . . . 36

29
 List of Tables

1.1 Users of the product . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Solution design constraints . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Workplaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Description of the workplace . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Business event list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Use case list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8 Business event list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.9 User functional requirements . . . . . . . . . . . . . . . . . . . . . . . . 16
1.10 Inverse user requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.11 Look and feel requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.12 Usability and Humanity Requirements . . . . . . . . . . . . . . . . . . 19
1.13 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.14 Expected physical environment . . . . . . . . . . . . . . . . . . . . . . 22
1.15 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1 Data dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2 Traceability matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

30