Software Development Lifecycle Report Infinity Parking System

(1)

GEBS Infinity Parking System

Software Development Lifecycle Report

Infinity Parking System

Author: Dan Ani

Date: 24 October , 2012 Status Draft

(2)

Document Summary

This document contains the software development lifecycle report for the Infinity Parking System. The requirements are initially focused on the Phase 1 functionality

Document Details

Project Infinity Parking System Status /

Version

Release 2.0 Reference

Code

Disclaimer

If you are reading this document on paper, it is an uncontrolled copy and you may not have the latest version. If you are updating this document, you may not be using the current version of the template. Please verify current versions with GEBS Reporting Arena. If this document contains a process you intend to follow, please ensure you are using the current version.

(3)

Version Control

Version Date Description of Changes Author

0.1 August 2010 Initial Draft Bill & Anne

0.2 October 2012 Version 1 Dan

Reference Documents

Name Version Location ReportingArena

Architectural Standards

v1.8 file://barney/Corporate%20Standards/AZASv1.8.pdf

Infinity Parking System

Feasability Study

v1.0 file://barney/Projects/Infinity/Infinity%20Feasability%20Study.pdf

(4)

Scope

The system includes car park entry and exit detection equipment, and entry/exit control. It includes a booking or allocation aspect that will interface to the current hotel booking system.

The payment part of the system covers reporting of usage to the existing hotel billing and payment system. Reporting of usage to management is included, as is ad-hoc reports on request of hotel staff for example to confirm whether and where a guest currently has a car parked.

Construction and maintenance of the parking lots is out of scope. Security and management of the parking lots is out of scope.

Context Diagram

Figure: 1 Parking System Context Diagram

Project Considerations

COTS equipment shall be used where possible

A range of technology options will be on offer to allow for adaptation to local requirements

Parking Lot entry exit subsystem

The choice of option will be dependent on local conditions. A trade study will be conducted to assess the most effective option, but this will have different answers for different cultures.

An option with no employee present will be unacceptable in some environments and preferred in others.

(7)

DOORS - Requirements Details

Page:7 of 21

High Tech Option

Detection of vehicles and identification as pre-booked or new visitor will be by camera with automated OCR

Redirection of guests who have arrived at the incorrect parking lot will be by dispensing a pre- programmed GPS device to direct the guest to the alternate lot

Medium Tech Option

Detection of vehicles and identification as pre-booked or new visitor will be by a data entry device at the entrance. Drivers will enter a predefined key or indicate that they are requesting entry as a visitor

Redirection of guests who have arrived at the incorrect parking lot will be by dispensing a paper map with directions to the alternate lot

Bloke with List Option

Detection of vehicles and identification as pre-booked or new visitor will be by an employee who has a list of all expected visitors

Redirection of guests who have arrived at the incorrect parking lot will be by the employee offering verbal directions and a paper map with directions to the alternate lot

Booking subsystem

Booking for hotel guests will be part of the hotel booking system and is out of scope for this project

Booking for parking only will be possible by a variety of methods, not all of which will be available in every location.

Where a hotel has a system already suitable for booking, this may be interfaced to the database holding registered vehicles

Payment subsystem

The payment subsystem will provide usage and billing information, it will interface with the booking system and with the existing hotel billing system

Transfer of funds is out of scope for this project

Reporting subsystem

Predefined reports will be produced to report usage to head office

The hotel will be able to produce ad-hoc reports of usage, for example to find out in which parking lot a particular guest has left his vehicle

Training

(8)

Training will be provided for all staff interfacing with the system

Training will be provided in various forms including just-in-time and just-in-case aspects

Requirements

Car park access

The car park access system allows vehicles to enter and leave the car park.

ID Requirement Description Priority Implementation WI's

FuncReq- 5

The system shall admit authorized vehicles High [ 90 ]Admit

authorized vehicles FuncReq-

6

The system shall admit unexpected vehicles when there are unutilized spaces

High FuncReq-

7

The system shall allow vehicles to leave when payment has been received

High FuncReq-

8

The system shall prevent vehicles from leaving when payment has not been received

Medium FuncReq-

25

The system shall inform the guest that he is at the wrong parking lot when there is insufficient availability at the current lot

Medium

FuncReq- 26

The system shall provide directions to the alternate parking lot when entry is refused

Low

Booking system

The booking system allows guests and visitors to book spaces in the car park and maintains a log of utilization.

ID Requirement Description Priority Implementation WI's FuncReq-

11

The system shall allocate parking spaces to guests

High [ 105 ]Design Details - Parking space allocation module

[ 106 ]Implementation - Parking spaces allocation module

FuncReq- 12

The system shall provide information on availability of parking spaces

Medium [ 106 ]Implementation - Parking spaces allocation module

FuncReq- The system shall provide information on Medium [ 107 ]Display parking prices

(9)

DOORS - Requirements Details

Page:9 of 21

13 parking prices FuncReq-

18

The system shall alert registered visitors to the availability of parking spaces

Low [ 108 ]Special rights for registered visitors FuncReq-

19

The system shall maintain a number of spaces as unavailable for visitors

Medium [ 108 ]Special rights for registered visitors FuncReq-

20

The system shall allow the hotel to set the number of reserved spaces for each day

Medium [ 109 ]Hotel parking management system FuncReq-

24

The system shall dynamically reallocate spaces when a guest arrives at the wrong parking lot

Low

Payment

The payment system allows guests and visitors to pay for parking by a variety of methods ID Requirement Description Priority Implementation WI's FuncReq-

14

The system shall allow guests to pay as part of their hotel check out

High [ 97 ]Implementation - Payment as part of check out process

[ 98 ]Design Details - Payment as part of check out process

FuncReq- 15

The system shall allow visitors to pre-pay for parking

Low [ 100 ]Implementation - Pre-pay for parking

FuncReq- 16

The system shall allow payment to be made at the hotel reception

High [ 102 ]Implementation - Payment to be made at the hotel reception [ 103 ]Detailed Design - Payment to be made at the hotel reception FuncReq-

17

The system shall allow visitors to be invoiced for parking

Low [ ]

Reporting

9

The system shall provide weekly reports of daily car park utilization.

Medium [ 111 ]Design report templates

[ 112 ]Implementation - Reporting Engine FuncReq- The system shall provide weekly reports Low [ 112 ]Implementation -

(10)

10 of car park revenue Reporting Engine FuncReq-

27

The system shall provide ad-hoc reports of where a guest is parked (which lot)

Low

Availability

33

The system shall allow bookings to be made between 06:00 and 02:00 every day

Low [ 114 ]Design and

Implementation - DB tables for Parking scheduler

[ 115 ]Parking Scheduler FuncReq-

34

The system shall allow vehicles to access the car park between 06:00 and 02:00 every day

Low [ 92 ]Park between 6.00 - 2.00

FuncReq- 35

The system shall have a manual override available when the system is in operable

Medium [ 93 ]Manual override available when the system is in operable

Localization

ID Requirement Description Priority Implementation

WI's FuncReq-

37

The system shall support up to three languages concurrently, selected by the hotel

Low FuncReq-

38

Aspects of the solution may be replaced by human operators to fit with local customs

High FuncReq-

39

Technology variations will be supported to fit with local customs

High

(11)

RTC - Implementation Details

Page:11 of 21

Requirements implementation 90 - Admit authorized vehicles

The system shall admit authorized vehicles.

ID Type Project Area Owner Priority Estimate Status Validated By

90 Requirement Change Request

Parking System (Development)

Dan Ani Medium 16 Applied 5: Admit authorized

vehicles

92 - Park between 6.00 - 2.00

Dan Ani Medium 2 Created

93 - Manual override available when the system is in operable

The system shall have a manual override available when the system is in operable. The parking administrator should be able to change the parking scheduler daily.

Dan Ani Medium 2 Assigned 6: Manual override

(12)

97 - Implementation - Payment as part of check out hotel process

Implement the payment module for: "Payment as part of check out process".

The implementation should follow the design details described in WI: "Design Details - Payment as part of check out process"

97 Task Parking System

(Development)

Dan Ani Medium 80 In Progress 1: Payment as part of hotel check out process

98 - Design Details - Payment as part of check out process

Simple solution design for planning purposes.

(Development)

Dan Ani Medium 8 In Progress

102 - Implementation - Payment to be made at the hotel reception

Create a payment method to allow the user to pay for parking at the hotel reception.

(Development)

Dan Ani Medium 40 New 2: Test payment process at

the hotel reception

(13)

Page:13 of 21

103 - Detailed Design - Payment to be made at the hotel reception

Create the detailed design for: "Payment to be made at the hotel reception".

(Development)

Dan Ani Medium 8 New

105 - Design Details - Parking space allocation module

Design the system that will allocate parking spaces to guests

(Development)

Dan Ani High 12 In Progress

106 - Implementation - Parking spaces allocation module

Based on provided architecture, implement the system that will allocate parking spaces and will provide information on availability of parking spaces

(Development)

Dan Ani Medium 40 Done

107 - Display parking prices

Display parking prices depending on the parking spot and on the amount of hours

(Development)

Dan Ani Unassigned 12 In Progress

(14)

108 - Special rights for registered visitors

The registered visitors should be able to see/check the availability of parking spaces. A number of available spaces

(Development)

Dan Ani Unassigned 12 New

109 - Hotel parking management system

The hotel should be able to manage the parking system.

(Development)

Dan Ani Low 10 New

111 - Design report templates

4 different templates need to be designed for reporting needs.

(Development)

Dan Ani Unassigned Undefined New

(15)

Page:15 of 21

112 - Implementation - Reporting Engine

Implement a reporting engine based on Rational Publishing Engine API. The reporting engine should support: word, pdf and html output formats.

(Development)

Dan Ani High 30 New

114 - Design and Implementation - DB tables for Parking scheduler

Design the Model and the DB tables for parking scheduler

(Development)

Unassigned Unassigned Undefined New

115 - Parking Scheduler

Implement the parking scheduler module. The module should be configurable - the parking administrator should have the possibility to change the availability hours (start and end hours)

(Development)

Unassigned Unassigned Undefined New

100 - Implementation - Pre-pay for parking

Create a "pre-pay" system for parking.

100 Task Parking System Dan Ani Medium 40 New 3: Test "Pre-Pay" Paying

(16)

(Development) system

(17)

RQM - Testing Details

Page:17 of 21

Requirements validation

Test Case: 1 - Payment as part of hotel check out process

The client should be able to pay for parking when he checks out from the hotel.

Test Results:

Date Result Details

2012-09-28 01:41:18 passed Pass with no fails.

2012-10-17 09:20:33 incomplete Not working if the client pays with cache.

2012-10-17 09:37:31 passed Log in into the payment system was solved.

Test Case: 2 - Test payment process at the hotel reception

The customer shall be able to pay for parking at the hotel reception.

Test Case: 3 - Test "Pre-Pay" Paying system

Test the parking "pre-pay" paying system.

Pre-Condition:

Purchase a parking voucher:

- 25$ minim amount - 100$ maxim amount Test Case Design:

At entrance:

1) If there are available spots in the parking then the parking gate will open.

At exit:

(18)

1) Insert the Parking Card into the Parking POM.

2) The system will calculate the total fee for parking.

3) The amount of money from the Parking card is checked.

Possible actions:

1) There is enough money on the card. The parking gate will open.

2) The amount of money is not enough. The parking gate will remain close.

Test Results:

Date Result Details

2012-10-24 11:10:01 passed Passed both the entrance and exit conditions.

Test Case: 5 - Admit authorized vehicles

The system shall admit all authorized vehicles.

Pre-Condition:

1. System must be operational.

2. Access date must be during the Card validity period.

3. Car height and weight must be equal or lower than 2m and 2.000kg Test Case Design:

1. Set the system into operable mode.

2. Simulate entry attempt for a car having a valid card (prepaid period valid), height no more than 2m and under 2.000kg.

3. Simulate entry attempt for a car having a valid card (prepaid period valid) that starts in the day of the entry attempt, height no more than 2m and under 2.000kg.

4. Simulate entry attempt for a car having a valid card (prepaid period valid) that ends in the day of the entry attempt, height no more than 2m and under 2.000kg.

(19)

RQM - Testing Details

Page:19 of 21

Test Case: 6 - Manual override

Manual override available when the system is in operable mode

Pre-Condition:

1. System must be operational.

2. System must request security code after Key Sequence pressed to start Admin menu.

3. System must allow connection with computer via USB cable.

Test Case Design:

1. Press the Key Sequence in order to display the Welcome Admin menu.

2. Enter the Password and once inside the system menu select to modify the Date and Time.

3. Navigate to the Vehicle Permission menu and change the allowed height and weight.

4. Using a USB cable, connect the System to a Computer having Infinity Parking Manager installed.

5. Using the Infinity Parking Manager interface from your computer navigate to the Date and Time area and change them.

6. Using the Infinity Parking Manager interface from your computer navigate to the Vehicle Permission menu and change the allowed height and weight.

7. Having several modifications made to the system simulate a power break by unplug/replug the power cord.

Test Results:

Date Result Details

2012-10-24 10:40:33 passed Passed all 7 steps.

2012-10-24 10:44:34 inconclusive 2. Enter the Password and once inside the system menu select to modify the Date and Time.

Result: Date and Time parameters are not visible.

(20)

Requirements coverage report

Covered Requirements

ID Description Status

5 The system shall admit authorized vehicles Agreed

11 The system shall allocate parking spaces to guests Agreed 12 The system shall provide information on availability of parking spaces Unconfirmed 13 The system shall provide information on parking prices Proposed 18 The system shall alert registered visitors to the availability of parking spaces Proposed 19 The system shall maintain a number of spaces as unavailable for visitors Proposed 20 The system shall allow the hotel to set the number of reserved spaces for

each day

Proposed 14 The system shall allow guests to pay as part of their hotel check out Agreed 15 The system shall allow visitors to pre-pay for parking Proposed 16 The system shall allow payment to be made at the hotel reception Agreed 17 The system shall allow visitors to be invoiced for parking Proposed 9 The system shall provide weekly reports of daily car park utilization. Proposed 10 The system shall provide weekly reports of car park revenue Proposed 33 The system shall allow bookings to be made between 06:00 and 02:00 every

day

Supp_Assess 34 The system shall allow vehicles to access the car park between 06:00 and

02:00 every day

Supp_Assess 35 The system shall have a manual override available when the system is in

operable

Proposed

Figure: 2 Covered Requirements by Status

Non Covered Requirements

ID Description Status

6 The system shall admit unexpected vehicles when there are unutilized spaces

Agreed 7 The system shall allow vehicles to leave when payment has been received Agreed 8 The system shall prevent vehicles from leaving when payment has not been

received

Proposed 25 The system shall inform the guest that he is at the wrong parking lot when Supp_Assess

(21)

System Development Lifecycle Report October 2012

Page:21 of 21

there is insufficient availability at the current lot

26 The system shall provide directions to the alternate parking lot when entry is refused

Stake_Assess 24 The system shall dynamically reallocate spaces when a guest arrives at the

wrong parking lot

Agreed 27 The system shall provide ad-hoc reports of where a guest is parked (which

lot)

Proposed 37 The system shall support up to three languages concurrently, selected by the

hotel

Proposed 38 Aspects of the solution may be replaced by human operators to fit with local

customs

Proposed 39 Technology variations will be supported to fit with local customs Proposed

Figure: 3 Non Covered Requirements by Status

Requirements coverage report:

Total covered requirements:16 Total non-covered requirements:10

Software Development Lifecycle Report Infinity Parking System