First Iteration Of Elaboration
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View First Iteration Of Elaboration as PDF for free.
More details
- Words: 3,605
- Pages: 25
Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, main success scenario and alternate extensions are revised. Receive car fully dressed use case is added
Author Safa Bacanlı, Tuna Karaman Group
FULLY DRESSED USE CASE: RESERVE CAR Use-case Name
Reserve Car
Scope
Car Reservation System
Level:
User-goal
Primary Actor
Staff/Manager
Stakeholders & Interest: Customer: Wants to reserve a car and fast service with minimum effort. Staff: Wants car reservation operations easily and quickly. Company: Wants accurate records of the cars and satisfy customer interests and wants to ensure that all the needed information is collected from the customer. Wants fast update of the car inventory. Manager: Wants to be able to quickly perform adding a car to the inventory and removing a car from the inventory. Preconditions:
Staff is identified and authenticated.
Success Guarantees:
Car record updated. Customer information is taken. Updated car
situation is prompted.
Main Success Scenario: 1.
Customer arrives at/ calls the office to rent a car.
2.
Staff starts a new reservation.
3.
Staff asks the group of the car, reservation period, delivery and return addresses.
4.
System displays the result of the search and available dates for reservation and price.
5.
Customer approves the reservation.
6.
Staff checks system if customer already has an account.
7.
System returns that customer does not have an account
8.
Staff creates a new customer account and confirms the reservation.
9.
System updates the status of the car to “Reserved”.
Alternate Extensions: a) At any time customer changes his/her mind. 1. Staff cancels the reservation process. 3a. Customer has no idea about which group of car to reserve. 1. Staff searches the available cars for the period that customer wants. 2. Staff shows the list of available cars. 3. Customer chooses a car. 3a. Customer does not choose a car. 1. Customer leaves without renting a car. 4a. Required group of cars are not available for given period. 1. Staff offers the upper group for the same price. 1a. Customer leaves without renting a car. 2. Customer accepts the offer.
3. Higher group of car is selected for the customer. 5a. Customer does not approve the price. 1. Staff shows the lower groups with fewer prices. 2. Customer chooses one of the lower model cars. 2a. Customer does not want to rent a lower model car. 1. Customer leaves without renting a car. 3. Staff starts a new reservation for that car. 7a. Customer already has an account in the system 1. Reservation is continued using existing customer account.
Special Requirements: Large panel monitor. Text must be seen from 1 meter Credit authorization response within 1 minute. User-friendly system should be provided.
Technology and Data Variations List: Different account types for Staff, manager and administrator Credit card is read by POS machine or credit card number is entered from keyboard. Customer information is taken from customer via telephone.
Open Issues: Customer decides to pay by cheque or in cash. Customer takes the car and never returns it back. Also the credit card is blocked. Frequency of Occurrence: Occasionally
FULLY DRESSED USE CASE DESIGN: RECEIVE CAR Use case name: Receive car Scope: Car Rental System Level: User-goal Primary Actor: Staff/Manager Stakeholders and Interests: Staff: Wants to receive the car and fast service with minimum effort. Manager: Wants the receive process does not take much time. Company: Wants to accurately update the records Customer: Wants to return the car as fast as possible. Preconditions: Staff is identified and authenticated. Customer came to office. Success Guarantee: Car record is updated. Receipt is printed. Main Success Scenario 1. Customer returns the car. 2. Staff checks whether the car return conditions are satisfied. 3. Staff searches the system for rent record of the customer. 4. System returns the rent record. 5. Staff checks if the return date and reservation deadline matches. 6. Staff updates the rent record. 7. System deletes the rent record, and car state is set free.
Alternate Extensions 2a. Car is involved in a traffic accident.. 1. Customer gives the accident report. 1a. Customer does not have the accident report. 1. Service price is charged from the customer. 2. Car status is changed to at service. 2. Car status is changed to at service. 2b. Customer expressed that car is broken down. 1. A new car is reserved and delivered to the customer. 2. Broken car is sent to service and car status is set to at service. 2c. Fuel level is below the required fuel level. 1. Customer is charged with a constant low fuel level fine. 4a. Rent record is not available. 1. Reservation record is checked. 2. Customer is asked to show receipt, so that it will be ensured that money is paid. 5a. Car is returned before return date. 1. Stoppage amount is calculated. 2. Unused day price is paid back without corresponding stoppage.
Special Requirements: Checking fuel level of the car. Providing accident report and contacting to insurance company in case of an accident. Technology and Data Variations List: None Frequency of Occurrence: Occasionally Open Issues: -What are the tax law variations? -What modifications are needed to be done for different companies?
Casual Format Use Cases
Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, three new casual use cases added
Author Yaşar Eren Biri, Uğur Bilen Yaşar Eren Biri, Uğur Bilen
Cancel Reservation: Main Success Scenario: Customer contacts to the office, requesting a cancel of reservation. Reservation info is checked in the system and the reservation is cancelled. Alternate Scenarios: If the reservation info is not found in the system, system returns a warning message, which indicates that no matching reservation registry is found in the system. In that case, customer is
informed that he does not have an active reservation at the moment and no cancel operation is necessary. If the cancel operation is requested less than 24 hours before the delivery date, customer is informed and charged the late cancellation fine. Fine is charged from the credit card whose information taken from the customer during the reservation process.
Manage Rent Period Main Success Scenario: Customer contacts to the office, requesting to extend or reduce reservation period. Reservation info is checked in the system and after checking that no period conflictions occur between other reservations, reservation period is updated. Alternate Scenarios: If the reservation info is not found in the system, system returns a warning message, which indicates that no matching reservation registry is found in the system. In that case, customer is informed that he does not have an active reservation at the moment and a new reservation is made according to the requirements of customer. If the reserved car is not available in case of an extension request, customer is informed and another (probably a higher model) car is provided for that period. If the customer requests to reduce reservation period, customer will be charged with a slight percentage of daily rental price for the number of days reservation is reduced.
Manage Car: Main Success Scenario: Manager logs into system to add or remove a car. To add a new car, manager goes to add car page and enters the properties of the new car to be added and confirms the operation. The system adds the car to the car catalog. To delete a car, manager selects the car from catalog or by search. Car can be deleted from the system only if it is in free state. Alternate Scenario: The car, which manager wants to remove is on use or at service. Manager cannot remove the car and cancels the operation.
Brief Format Use Cases Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, main success scenario and alternate extensions are revised
Author Uğur Bilen, Yaşar Eren Biri Safa Bacanlı, Yaşar Eren Biri, Uğur Bilen
Reserve Fleet: A customer who would probably be a company contacts to an office requesting to reserve multiple number of cars. The staff member uses the car rental system to reserve multiple numbers of cars. The system checks the availability of such reservation on given period of time and required cars. If customer confirms reservation, staff member adds customer information to reservation and saves the reservation.
Set Service Period: In cases like break down, accident or reaching casual service km; car will be sent to service. Approximate service period of the car will be added to car description by staff. Deliver Car: A customer whose rent period begins arrives at an office to take his car. Payment is handled at this point. Customer pays the rental price and system prints the receipt and adds the payment type to customer account. System changes the car status from reserved to rented, after printing the receipt. Car is delivered to the customer afterwards. Deliver Fleet: A customer (probably with multiple drivers) whose rent period begins arrives at an office to take his fleet. Payment is handled at this point. Customer pays the rental price and system prints the receipt and adds the payment type to customer account. System changes the fleet status from reserved to on rent after printing the receipt, and updates the state of each car in the fleet. Fleet is delivered to the customer afterwards. View Car State: A car’s current status may be required for several reasons. A staff member directly searches the system from cars VIN number or selects the car from car catalog. The system presents the information of the selected car.
Receive Fleet: A customer arrives at a return point with the fleet he rented. A staff member checks each car one by one whether they satisfy returning conditions. The system makes the checkout of the customer and updates state of each car in the fleet. Manage Office: Administrator logs into the system to add or remove an office. To add a new office, administrator goes to add office page and enters the properties of the office. To create an office, at least one manager and one staff member should be assigned to the office. Manage User: Administrator logs into the system to add or remove a user account. To add a new user, administrator goes to create account page, enters personal information of the user, determines whether the new user is a manager or staff member and assigns the new user to an office. To delete a user account, administrator selects the user from the user catalog or by search and deletes the account.
Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, main success scenario and alternate extensions are revised
Author Yaşar Eren Biri Yaşar Eren Biri
Use Case Diagram
Vision Version Inception draft First Iteration of Elaboration
Date
Description First Draft, will be a base for the 9.10.2007 second draft Human Factors removed, Information 28.10.2007 in domains of interest and functionality added
Author Uğur Bilen Safa Bacanlı Yaşar Eren Biri, Tuna Karaman
Introduction: In our project we design and implement a car rental system, which will be used in car renting offices. The system keeps information about car and connects different offices through a network. Problem Statement: In the car renting company, processes like reservation and connection between two offices are managed by telephone calls between costumer-office and two different offices. This costs more in terms of time and money. In addition to that, hardcopy files were used to keep track of rented and available cars, which make workers’ life worse. Our system connects offices through network and controls the status of cars so it is much easier to control the information and status of cars.
Summary of System Features: Rental Records Customer Management User Management (administrator, manager, staff) Payment Registry (cash, credit, check) Reservation Records Accounting Records (income, expenditure) System administration for users: security, information tables High Level Goals and Problems of the Stakeholders.
High level goal
Priority
Problems and Concerns
Current Solutions
Fast and integrated renting process
High
Slow processing speed of the needs of the customer related
Building a car Rental software that can communicate with other offices
Getting access to car database easily and faster
Medium Difficulty in keeping track of the cars, reaching the record after some time, as they were foldered manually by Staff.
Building a car Rental software that keeps the record of the cars
User Level Goals The users (and external systems) need software to fulfill these goals. Staff: process reservations, handle return of the car, update car state, manage reservation and rental. System Administrator: add or remove staff or manager accounts Manager: add a new car record or remove a car record.
SUPPLEMANTARY SPECIFICATION DOCUMENT Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, revised
Author Uğur Bilen, Safa Bacanlı Yaşar Eren Biri, Tuna Karaman
1. Other Requirements and Constraints Introduction This document is the repository of all Car Rental Software requirements not captured in the use cases. 2. Usability Speed, ease and error-free processing are paramount in sales processing, as the customer wishes to leave quickly. 3. Reliability If there is a failure to use credit card transfer machine, try to solve it with a local solution in order to complete a receive process. 4. Performance As mentioned under human factors, customers want to complete the “taking the rented car” or reservation process. 5. Supportability 5.1 Adaptability Our software will work in every office. Adapting the software to new computers is not a problem. 5.2. Configurability Configuration is not a problem, as software does not need any hardware configuration
6. Implementation Constraints
Software will be programmed in Java and XML will not be used. Excel or text file can be used for database of the car records. 7. Interfaces 7.1 Noteworthy Hardware and Interfaces: Receipt printer 7.2 Software Interfaces: We will have different systems for different processes like making reservation, canceling reservation, car search and etc. so we need to have different interfaces for these different processes. 8.
Information in Domains of Interest Pricing In addition to the pricing rules section, note that rental prices, fines and service price equivalent has different values depending on the economical wealth at the location of the office. Offices maintain original prices even if there is a markdown depending on the season, for accounting and tax reasons.
Credit Payment Handling Validity of the credit card information taken from the customer is checked. Even the customer already has an account; credit card of the customer is validated before any reservation is done for that customer. Tax Regulations Tax calculations can be very complex, and regularly change in response to legislation at all levels of government. Therefore, delegating tax calculations to third-party software (of which there are several available) is advisable. Tax may be owing to city, region, state, and national bodies. Some items may be tax exempt without qualification, or exempt depending on the buyer or target recipient (for example, a farmer or a child).
Customer Identifiers The Car Rental System identifies customers with several properties. Main identifier for a customer is license number, which is unique for every individual. Having a validated license number also verifies that customer is a legitimate driver.
Car Identifiers The Car Rental System identifies cars with several properties. Main identifier for a car is its VIN number which is unique worldwide. Plate number is also a unique identifier and can be used.
9.
Functionality Customer Identification License number is the major identifier of a customer. Fine Calculation Fine calculator calculates fine for inappropriate customer acts: early or late return, unsatisfied car return conditions, late reservation cancellation. Security All usage requires user authentication. Pluggable Rules At various scenario points of several use cases ( to be defined) support the ability to customize the functionality of the system with a set of arbitrary rules that execute at that point or event
10.
Documentation Read me text file will be available with the program. Vision Report will also be ready for further detail.
11.
Packaging
Software will be programmed in Java and can be prepared as exe, jar (JRE should be installed to the system) or separate java files according to need of customer.
First Iteration of Elaboration
24.10.2007
First Draft, will be a base for the second draft
Safa Bacanlı, Tuna Karaman
Business (Domain) Rules ID
Rule
Changability Source
Rule1 Credit payment reversals may only be paid as a credit to the buyer’s credit account, not as a cash.
Low
Credit Authorization Company Policy
Rule2 If car is returned late, customer will be charged with 15% fine per day
Low
Credit Authorization Company Policy
Rule3 Car is delivered to customer with fully loaded tank. Car is received from customer with fully loaded tank.
Low
Credit Authorization Company Policy
Rule4 If customer does not return car back with fuel level full, constant fine is charged from the customer: which is taken from customer.
Low
Credit Authorization Company Policy
Rule5 If a car breaks down during customer use, customer is immediately given a new car from the same group. If a car in that group is not available, higher group of car is provided.
Low
Credit Authorization Company Policy
Rule6 If reservation is cancelled in last 24 hours, 50% of the rent fee is taken from customer.
Low
Credit Authorization Company Policy
Rule7 During reservation, even if the customer indicates that he will pay by cheque or cash, credit card information is still required for security reasons.
Low
Credit Authorization Company Policy
Requirements Version First Iteration of Elaboration
Date 28.10.2007
Description Second draft, requirements for the fşrst iteration is written
Author Yaşar Eren Biri
The requirements for the first iteration of the Car Rental System application follow:
Implement a basic, key scenario of the Reserve Car use case: customer contacts an office and staff communicating with the customer reserves a car for the customer for a specific period of time.
Implement a Start Up use case as necessary to support initialization needs of the iteration.
Nothing fancy or complex is handled, just a simple happy path scenario and the design and implementation to support it.
There is no collaboration with external services, such as a tax calculator, fine calculator, credit card authorization, accounting system.
Customer determines where the car will be delivered and returned and the reservation period.
Customers are registered to system and are determined afterwards by their driver’s license number if they are new or already have an account.
Car description includes properties of car. Included information is: brand, model, year, color, state and most importantly VIN number for the car to be determined explicitly.
A car has four states: free, at service, reserved, rented.
In iteration-1 there is only one office, one manager, one staff, one type of car, there are no previously registered customers.
Simulate car reservation requiring no actual car description, other than a specified car group and an imaginary car.
Pricing regulations are not applied.
The design and implementation of the supporting UI, database, and so forth, would also be done, but is not covered in any detail.
Version First Iteration of Elaboration
Date 28.10.2007
Description Second draft, domain model is prepared
Domain Model
Author Group
First Iteration of Elaboration
28.10.2007
Second draft, system sequence diagram of two fully dressed use cases prepared
System Sequence Diagrams Reserve Car:
Yaşar Eren Biri
Receive Car:
GLOSSARY Inception Draft
9.10.2007
First Iteration of Elaboration
24.10.2007
First Draft, will be a base for the second draft Second draft, glossary is extended with new terms
Term
Definitions-information
Administrator
Computer specialist who add / remove user. Also manages the system.
Office
Car reservation and delivery checkpoints. At least one manager and one staff member should work on the office
Car Description
Name, brand, model, year, VIN number, plate number, state
Staff
Worker in office who serves the customers
Manager
Director of the office
Manage Car Service Period
Times for car to go washing and repair
Manage User
Adding a new user to system or deleting the existing one from
Uğur Bilen Yaşar Eren Biri
Format
Validation rules
Aliases
VIN number (Vehicle Identification Number) is a 17 character ID for vehicles. Plate number depends on the country where car is located.
Traffic Department validates authenticity of the VIN and plate number
VIN: Universal Product Code
Check Car
Controlling whether car is brought how it is given to customer
Car Return Conditions
Customer should return the car without any damage and a full fuel tank.
Receive process
Process of taking car from the customer after rent period
Confirm Reservation
Saving a reservation including a specific car from a car group, information of customer reserving the car.
Customer Information
Name, address, phone, valid credit card info, license number
Car Status Updated
Shows whether the car is available or not
Credit card number is a 16 digit number
Authorization service checks the validity of the given 16 digit number
Universal credit card number format
Work Distribution Total Hours Worked as a Group: 20.5 hours between 24/10/2007-28/10/2007
Safa Bacanlı: Elaboration of Receive Car 3, Business Rules 3, Elaboration of Supplementary Specification Report 4. Tuna Karaman: Elaboration of Receive Car 3, Business Rules 3. Uğur Bilen: Elaboration of Reserve Car & Receive Car 4, Casual Format Use Cases 2, Elaboration of Supplementary Specification Report 4. Yaşar Eren Biri: Requirements of the first iteration 2, Drawing Domain Model 5, System Sequence Diagrams 3.
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, main success scenario and alternate extensions are revised. Receive car fully dressed use case is added
Author Safa Bacanlı, Tuna Karaman Group
FULLY DRESSED USE CASE: RESERVE CAR Use-case Name
Reserve Car
Scope
Car Reservation System
Level:
User-goal
Primary Actor
Staff/Manager
Stakeholders & Interest: Customer: Wants to reserve a car and fast service with minimum effort. Staff: Wants car reservation operations easily and quickly. Company: Wants accurate records of the cars and satisfy customer interests and wants to ensure that all the needed information is collected from the customer. Wants fast update of the car inventory. Manager: Wants to be able to quickly perform adding a car to the inventory and removing a car from the inventory. Preconditions:
Staff is identified and authenticated.
Success Guarantees:
Car record updated. Customer information is taken. Updated car
situation is prompted.
Main Success Scenario: 1.
Customer arrives at/ calls the office to rent a car.
2.
Staff starts a new reservation.
3.
Staff asks the group of the car, reservation period, delivery and return addresses.
4.
System displays the result of the search and available dates for reservation and price.
5.
Customer approves the reservation.
6.
Staff checks system if customer already has an account.
7.
System returns that customer does not have an account
8.
Staff creates a new customer account and confirms the reservation.
9.
System updates the status of the car to “Reserved”.
Alternate Extensions: a) At any time customer changes his/her mind. 1. Staff cancels the reservation process. 3a. Customer has no idea about which group of car to reserve. 1. Staff searches the available cars for the period that customer wants. 2. Staff shows the list of available cars. 3. Customer chooses a car. 3a. Customer does not choose a car. 1. Customer leaves without renting a car. 4a. Required group of cars are not available for given period. 1. Staff offers the upper group for the same price. 1a. Customer leaves without renting a car. 2. Customer accepts the offer.
3. Higher group of car is selected for the customer. 5a. Customer does not approve the price. 1. Staff shows the lower groups with fewer prices. 2. Customer chooses one of the lower model cars. 2a. Customer does not want to rent a lower model car. 1. Customer leaves without renting a car. 3. Staff starts a new reservation for that car. 7a. Customer already has an account in the system 1. Reservation is continued using existing customer account.
Special Requirements: Large panel monitor. Text must be seen from 1 meter Credit authorization response within 1 minute. User-friendly system should be provided.
Technology and Data Variations List: Different account types for Staff, manager and administrator Credit card is read by POS machine or credit card number is entered from keyboard. Customer information is taken from customer via telephone.
Open Issues: Customer decides to pay by cheque or in cash. Customer takes the car and never returns it back. Also the credit card is blocked. Frequency of Occurrence: Occasionally
FULLY DRESSED USE CASE DESIGN: RECEIVE CAR Use case name: Receive car Scope: Car Rental System Level: User-goal Primary Actor: Staff/Manager Stakeholders and Interests: Staff: Wants to receive the car and fast service with minimum effort. Manager: Wants the receive process does not take much time. Company: Wants to accurately update the records Customer: Wants to return the car as fast as possible. Preconditions: Staff is identified and authenticated. Customer came to office. Success Guarantee: Car record is updated. Receipt is printed. Main Success Scenario 1. Customer returns the car. 2. Staff checks whether the car return conditions are satisfied. 3. Staff searches the system for rent record of the customer. 4. System returns the rent record. 5. Staff checks if the return date and reservation deadline matches. 6. Staff updates the rent record. 7. System deletes the rent record, and car state is set free.
Alternate Extensions 2a. Car is involved in a traffic accident.. 1. Customer gives the accident report. 1a. Customer does not have the accident report. 1. Service price is charged from the customer. 2. Car status is changed to at service. 2. Car status is changed to at service. 2b. Customer expressed that car is broken down. 1. A new car is reserved and delivered to the customer. 2. Broken car is sent to service and car status is set to at service. 2c. Fuel level is below the required fuel level. 1. Customer is charged with a constant low fuel level fine. 4a. Rent record is not available. 1. Reservation record is checked. 2. Customer is asked to show receipt, so that it will be ensured that money is paid. 5a. Car is returned before return date. 1. Stoppage amount is calculated. 2. Unused day price is paid back without corresponding stoppage.
Special Requirements: Checking fuel level of the car. Providing accident report and contacting to insurance company in case of an accident. Technology and Data Variations List: None Frequency of Occurrence: Occasionally Open Issues: -What are the tax law variations? -What modifications are needed to be done for different companies?
Casual Format Use Cases
Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, three new casual use cases added
Author Yaşar Eren Biri, Uğur Bilen Yaşar Eren Biri, Uğur Bilen
Cancel Reservation: Main Success Scenario: Customer contacts to the office, requesting a cancel of reservation. Reservation info is checked in the system and the reservation is cancelled. Alternate Scenarios: If the reservation info is not found in the system, system returns a warning message, which indicates that no matching reservation registry is found in the system. In that case, customer is
informed that he does not have an active reservation at the moment and no cancel operation is necessary. If the cancel operation is requested less than 24 hours before the delivery date, customer is informed and charged the late cancellation fine. Fine is charged from the credit card whose information taken from the customer during the reservation process.
Manage Rent Period Main Success Scenario: Customer contacts to the office, requesting to extend or reduce reservation period. Reservation info is checked in the system and after checking that no period conflictions occur between other reservations, reservation period is updated. Alternate Scenarios: If the reservation info is not found in the system, system returns a warning message, which indicates that no matching reservation registry is found in the system. In that case, customer is informed that he does not have an active reservation at the moment and a new reservation is made according to the requirements of customer. If the reserved car is not available in case of an extension request, customer is informed and another (probably a higher model) car is provided for that period. If the customer requests to reduce reservation period, customer will be charged with a slight percentage of daily rental price for the number of days reservation is reduced.
Manage Car: Main Success Scenario: Manager logs into system to add or remove a car. To add a new car, manager goes to add car page and enters the properties of the new car to be added and confirms the operation. The system adds the car to the car catalog. To delete a car, manager selects the car from catalog or by search. Car can be deleted from the system only if it is in free state. Alternate Scenario: The car, which manager wants to remove is on use or at service. Manager cannot remove the car and cancels the operation.
Brief Format Use Cases Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, main success scenario and alternate extensions are revised
Author Uğur Bilen, Yaşar Eren Biri Safa Bacanlı, Yaşar Eren Biri, Uğur Bilen
Reserve Fleet: A customer who would probably be a company contacts to an office requesting to reserve multiple number of cars. The staff member uses the car rental system to reserve multiple numbers of cars. The system checks the availability of such reservation on given period of time and required cars. If customer confirms reservation, staff member adds customer information to reservation and saves the reservation.
Set Service Period: In cases like break down, accident or reaching casual service km; car will be sent to service. Approximate service period of the car will be added to car description by staff. Deliver Car: A customer whose rent period begins arrives at an office to take his car. Payment is handled at this point. Customer pays the rental price and system prints the receipt and adds the payment type to customer account. System changes the car status from reserved to rented, after printing the receipt. Car is delivered to the customer afterwards. Deliver Fleet: A customer (probably with multiple drivers) whose rent period begins arrives at an office to take his fleet. Payment is handled at this point. Customer pays the rental price and system prints the receipt and adds the payment type to customer account. System changes the fleet status from reserved to on rent after printing the receipt, and updates the state of each car in the fleet. Fleet is delivered to the customer afterwards. View Car State: A car’s current status may be required for several reasons. A staff member directly searches the system from cars VIN number or selects the car from car catalog. The system presents the information of the selected car.
Receive Fleet: A customer arrives at a return point with the fleet he rented. A staff member checks each car one by one whether they satisfy returning conditions. The system makes the checkout of the customer and updates state of each car in the fleet. Manage Office: Administrator logs into the system to add or remove an office. To add a new office, administrator goes to add office page and enters the properties of the office. To create an office, at least one manager and one staff member should be assigned to the office. Manage User: Administrator logs into the system to add or remove a user account. To add a new user, administrator goes to create account page, enters personal information of the user, determines whether the new user is a manager or staff member and assigns the new user to an office. To delete a user account, administrator selects the user from the user catalog or by search and deletes the account.
Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, main success scenario and alternate extensions are revised
Author Yaşar Eren Biri Yaşar Eren Biri
Use Case Diagram
Vision Version Inception draft First Iteration of Elaboration
Date
Description First Draft, will be a base for the 9.10.2007 second draft Human Factors removed, Information 28.10.2007 in domains of interest and functionality added
Author Uğur Bilen Safa Bacanlı Yaşar Eren Biri, Tuna Karaman
Introduction: In our project we design and implement a car rental system, which will be used in car renting offices. The system keeps information about car and connects different offices through a network. Problem Statement: In the car renting company, processes like reservation and connection between two offices are managed by telephone calls between costumer-office and two different offices. This costs more in terms of time and money. In addition to that, hardcopy files were used to keep track of rented and available cars, which make workers’ life worse. Our system connects offices through network and controls the status of cars so it is much easier to control the information and status of cars.
Summary of System Features: Rental Records Customer Management User Management (administrator, manager, staff) Payment Registry (cash, credit, check) Reservation Records Accounting Records (income, expenditure) System administration for users: security, information tables High Level Goals and Problems of the Stakeholders.
High level goal
Priority
Problems and Concerns
Current Solutions
Fast and integrated renting process
High
Slow processing speed of the needs of the customer related
Building a car Rental software that can communicate with other offices
Getting access to car database easily and faster
Medium Difficulty in keeping track of the cars, reaching the record after some time, as they were foldered manually by Staff.
Building a car Rental software that keeps the record of the cars
User Level Goals The users (and external systems) need software to fulfill these goals. Staff: process reservations, handle return of the car, update car state, manage reservation and rental. System Administrator: add or remove staff or manager accounts Manager: add a new car record or remove a car record.
SUPPLEMANTARY SPECIFICATION DOCUMENT Version
Date
Inception draft
9.10.2007
First Iteration of Elaboration
28.10.2007
Description First Draft, will be a base for the second draft Second draft, revised
Author Uğur Bilen, Safa Bacanlı Yaşar Eren Biri, Tuna Karaman
1. Other Requirements and Constraints Introduction This document is the repository of all Car Rental Software requirements not captured in the use cases. 2. Usability Speed, ease and error-free processing are paramount in sales processing, as the customer wishes to leave quickly. 3. Reliability If there is a failure to use credit card transfer machine, try to solve it with a local solution in order to complete a receive process. 4. Performance As mentioned under human factors, customers want to complete the “taking the rented car” or reservation process. 5. Supportability 5.1 Adaptability Our software will work in every office. Adapting the software to new computers is not a problem. 5.2. Configurability Configuration is not a problem, as software does not need any hardware configuration
6. Implementation Constraints
Software will be programmed in Java and XML will not be used. Excel or text file can be used for database of the car records. 7. Interfaces 7.1 Noteworthy Hardware and Interfaces: Receipt printer 7.2 Software Interfaces: We will have different systems for different processes like making reservation, canceling reservation, car search and etc. so we need to have different interfaces for these different processes. 8.
Information in Domains of Interest Pricing In addition to the pricing rules section, note that rental prices, fines and service price equivalent has different values depending on the economical wealth at the location of the office. Offices maintain original prices even if there is a markdown depending on the season, for accounting and tax reasons.
Credit Payment Handling Validity of the credit card information taken from the customer is checked. Even the customer already has an account; credit card of the customer is validated before any reservation is done for that customer. Tax Regulations Tax calculations can be very complex, and regularly change in response to legislation at all levels of government. Therefore, delegating tax calculations to third-party software (of which there are several available) is advisable. Tax may be owing to city, region, state, and national bodies. Some items may be tax exempt without qualification, or exempt depending on the buyer or target recipient (for example, a farmer or a child).
Customer Identifiers The Car Rental System identifies customers with several properties. Main identifier for a customer is license number, which is unique for every individual. Having a validated license number also verifies that customer is a legitimate driver.
Car Identifiers The Car Rental System identifies cars with several properties. Main identifier for a car is its VIN number which is unique worldwide. Plate number is also a unique identifier and can be used.
9.
Functionality Customer Identification License number is the major identifier of a customer. Fine Calculation Fine calculator calculates fine for inappropriate customer acts: early or late return, unsatisfied car return conditions, late reservation cancellation. Security All usage requires user authentication. Pluggable Rules At various scenario points of several use cases ( to be defined) support the ability to customize the functionality of the system with a set of arbitrary rules that execute at that point or event
10.
Documentation Read me text file will be available with the program. Vision Report will also be ready for further detail.
11.
Packaging
Software will be programmed in Java and can be prepared as exe, jar (JRE should be installed to the system) or separate java files according to need of customer.
First Iteration of Elaboration
24.10.2007
First Draft, will be a base for the second draft
Safa Bacanlı, Tuna Karaman
Business (Domain) Rules ID
Rule
Changability Source
Rule1 Credit payment reversals may only be paid as a credit to the buyer’s credit account, not as a cash.
Low
Credit Authorization Company Policy
Rule2 If car is returned late, customer will be charged with 15% fine per day
Low
Credit Authorization Company Policy
Rule3 Car is delivered to customer with fully loaded tank. Car is received from customer with fully loaded tank.
Low
Credit Authorization Company Policy
Rule4 If customer does not return car back with fuel level full, constant fine is charged from the customer: which is taken from customer.
Low
Credit Authorization Company Policy
Rule5 If a car breaks down during customer use, customer is immediately given a new car from the same group. If a car in that group is not available, higher group of car is provided.
Low
Credit Authorization Company Policy
Rule6 If reservation is cancelled in last 24 hours, 50% of the rent fee is taken from customer.
Low
Credit Authorization Company Policy
Rule7 During reservation, even if the customer indicates that he will pay by cheque or cash, credit card information is still required for security reasons.
Low
Credit Authorization Company Policy
Requirements Version First Iteration of Elaboration
Date 28.10.2007
Description Second draft, requirements for the fşrst iteration is written
Author Yaşar Eren Biri
The requirements for the first iteration of the Car Rental System application follow:
Implement a basic, key scenario of the Reserve Car use case: customer contacts an office and staff communicating with the customer reserves a car for the customer for a specific period of time.
Implement a Start Up use case as necessary to support initialization needs of the iteration.
Nothing fancy or complex is handled, just a simple happy path scenario and the design and implementation to support it.
There is no collaboration with external services, such as a tax calculator, fine calculator, credit card authorization, accounting system.
Customer determines where the car will be delivered and returned and the reservation period.
Customers are registered to system and are determined afterwards by their driver’s license number if they are new or already have an account.
Car description includes properties of car. Included information is: brand, model, year, color, state and most importantly VIN number for the car to be determined explicitly.
A car has four states: free, at service, reserved, rented.
In iteration-1 there is only one office, one manager, one staff, one type of car, there are no previously registered customers.
Simulate car reservation requiring no actual car description, other than a specified car group and an imaginary car.
Pricing regulations are not applied.
The design and implementation of the supporting UI, database, and so forth, would also be done, but is not covered in any detail.
Version First Iteration of Elaboration
Date 28.10.2007
Description Second draft, domain model is prepared
Domain Model
Author Group
First Iteration of Elaboration
28.10.2007
Second draft, system sequence diagram of two fully dressed use cases prepared
System Sequence Diagrams Reserve Car:
Yaşar Eren Biri
Receive Car:
GLOSSARY Inception Draft
9.10.2007
First Iteration of Elaboration
24.10.2007
First Draft, will be a base for the second draft Second draft, glossary is extended with new terms
Term
Definitions-information
Administrator
Computer specialist who add / remove user. Also manages the system.
Office
Car reservation and delivery checkpoints. At least one manager and one staff member should work on the office
Car Description
Name, brand, model, year, VIN number, plate number, state
Staff
Worker in office who serves the customers
Manager
Director of the office
Manage Car Service Period
Times for car to go washing and repair
Manage User
Adding a new user to system or deleting the existing one from
Uğur Bilen Yaşar Eren Biri
Format
Validation rules
Aliases
VIN number (Vehicle Identification Number) is a 17 character ID for vehicles. Plate number depends on the country where car is located.
Traffic Department validates authenticity of the VIN and plate number
VIN: Universal Product Code
Check Car
Controlling whether car is brought how it is given to customer
Car Return Conditions
Customer should return the car without any damage and a full fuel tank.
Receive process
Process of taking car from the customer after rent period
Confirm Reservation
Saving a reservation including a specific car from a car group, information of customer reserving the car.
Customer Information
Name, address, phone, valid credit card info, license number
Car Status Updated
Shows whether the car is available or not
Credit card number is a 16 digit number
Authorization service checks the validity of the given 16 digit number
Universal credit card number format
Work Distribution Total Hours Worked as a Group: 20.5 hours between 24/10/2007-28/10/2007
Safa Bacanlı: Elaboration of Receive Car 3, Business Rules 3, Elaboration of Supplementary Specification Report 4. Tuna Karaman: Elaboration of Receive Car 3, Business Rules 3. Uğur Bilen: Elaboration of Reserve Car & Receive Car 4, Casual Format Use Cases 2, Elaboration of Supplementary Specification Report 4. Yaşar Eren Biri: Requirements of the first iteration 2, Drawing Domain Model 5, System Sequence Diagrams 3.
Related Documents
First Iteration Of Elaboration
November 2019 7
Vi. Elaboration Of Magna Carta
May 2020 8
Elaboration De Cv 070110
May 2020 2
Cs284 Formal Reuse Iteration
October 2019 8
44 Iteration Newton'smethod
November 2019 2