ITC508 Object Modelling- XYZ Car Park System/ Case Study

1. Identify and briefly describe the main functional and non-functional requirements for the major systems areas of the case study.

2. Explain the role of use cases for the creation of a domain model of the problem domain and draw use case diagrams for all systems in the case study that show all actors and use cases.

3. Draw a UML domain model class diagram for all systems in your chosen case study. Be as specific and accurate as possible, given the information provided. If needed information is not given, make realistic assumptions.

4. Review the functional and non-functional requirements for the major systems areas of the case study you have developed in question 1. Then, for each of the five design activity of SDLC, list and briefly describe some specific tasks required for each design activities (i.e., describing the environment, designing application components, user interfaces, the database, and software methods.

5. Develop a System Vision Document to give the total vision of the system and develop a work breakdown structure (WBS) for the project’s first iteration.

Introduction

XYZ Car Park System operates ten car parks in the city to allow the people to avail smart and easy parking services. With the expansion of the car parks, it is now required to develop a new and enhanced car parking system to control the system and its associated activities. The document covers the architecture and design components of the system.

Functional Requirements

Operational System

• Set up two customer types as ordinary and seasonal
• Allow season ticket holders to pay in advance for 3, 6 or 12 months
• Car park shall have reserved space for seasonal customers during weekdays
• Weekdays shall have 10% space reserved for seasonal customers
• No reserved space shall be present for seasonal customers during weekends (Brandenburg, 2016)

Entry to the Car Park

• Control pillar shall display ‘Press Button’ message once entry gates sense the vehicle through sensors
• Ordinary customer shall receive the ticket in five seconds and message shall change to ‘Take Ticket’
• In case of full use of space, message shall be displayed as ‘Full’
• Once there is a vacancy, ‘Press Button’ message shall be displayed
• Barrier should rise again once customer gets the ticket 
• Season ticket holders must be validated on the date of validity and customer
  
  type
• Barrier shall rise if validation made is correct
• Ticket for ordinary customer shall have a bar code with a unique number and date & time of issuing
• Vehicle count shall be updated in the system with every entry (Smartba, 2016)

Payment

• Payment system shall detect the bar code on the ticket
• Information from bar code and one in the system shall match
• LCD display shall alert the customer in case of mismatch and the ticket shall also come out from the slot 
• Attendant shall use office system to verify the mismatch and payment shall be allowed 
• In case of a match, the amount shall be displayed on LCD
• Absence of required change shall be notified through message on LCD display
• Notes/coins shall be allowed to be inserted and a validation check shall be performed on them. Amount should get accumulated accordingly 
• Validation of the ticket shall be complete with balance as zero
• Ticket shall be ejected after full payment and details of date and time shall be printed on it 
• Printing of the receipt shall be done only if the customer wishes to obtain it 
• If the customer desires printed receipt then the details shall be printed on it and a receipt shall be generated 
• A duration of maximum 15 minutes shall be spent to collect ticket after completion of payment to leave the parking space (Onedesk, 2016)

Leaving the Car Park

• Exit gates shall display the message as ‘Insert Ticket’ upon sensing the vehicle 
• If the duration between payment confirmation and insertion of ticket is less than 15 minutes then the barrier shall rise
• In case of increase in the duration as 15 minutes attendant shall have the ability to raise the barrier remotely 
• The vehicle count in the system shall be updated when a vehicle exits the car park 
• Attendant shall be allowed to update the status of the pay station after every 10 seconds 
• Season ticket holders shall be allowed to make exit without visiting pay station 
• As soon as card is inserted by the season ticket holders, the barrier shall rise (Ifla, 2016)

Security Visit Recording

• The system shall record the entry and exit of security guards in and from the car park by recording the time details in both cases 
• Entry and exit of security guards shall be monitored with the rules applicable as that with seasonal customers
• Security companies shall be provided with necessary cards for their guards (Requirementsnetwork, 2016)

Management System

Fault Recording

• Faults associated with the system shall be managed by recording them with all the associated details 
• Maintenance Company shall be immediately notified in case of faulty equipment 
• Other problems shall be handled by notifying the direct labor organization of the city administration 
• The information around the fault fixation shall be stored in the system (Patton, 2016)

Security SLA

• A report shall be maintained around the security guards and their entry and exits to the car park to validate it against the finalized contracted numbers

Season Tickets

• Season tickets shall be provided to the maintenance companies with the same rules applicable as that of the seasonal customers
• The cards that are issued shall be valid for a period of 3 months, 6 months or 12 months 
• A renewal form for the season ticket shall be sent two weeks prior of the expiry date 
• Expiry date shall be updated once renewal is made 

Other Management Requirements

• Monitoring and tracking of the tickets issues in a certain period of time such as one year shall be recorded

Non-Functional Requirements

• The car park system shall have the non-functional system quality as availability of the system which shall ensure that the system is always available for all the customer types and security guards along with the management resources
• Usability is another non-functional requirement that must be available and shall be reflected in the car park system so that the customer experience is excellent
• The car park system shall have the non-functional system quality as scalability of the system which shall ensure that the system can be scaled up and scaled down as per the requirements that are provided
• Performance is another non-functional requirement that must be available and shall be reflected in the car park system so that the time that is required in activities such as obtaining a ticker, exiting from the park, making payments and likewise is very short
• The car park system shall have the non-functional system quality as reliability of the system which shall ensure that the system is reliable and provides only the valid information to the customers in every scenario
• Affordability is another non-functional requirement that must be available and shall be reflected in the car park system so that the system can be used by one and all  (Loewy, 2016)
• The car park system shall have the non-functional system quality as recoverability of the system which shall ensure that the system is recoverable in all scenarios and there is minimum downtime involved
• Maintainability is another non-functional requirement that must be available and shall be reflected in the car park system so that the system can be easily maintained by the maintenance team members

Role of Use Cases

The use cases will have an important role in the system as the information associated with the actors involved in XYZ car park system and the activities that will be performed by them will be informed through the medium of the use cases (Gomaa & Olimpiew, 2016).

There will be many actors that will be involved with the system such as customers, management team, security team, admin, attendant and many more. The use cases will elaborate the actions that each of the actors will perform to explain the design of the system in an elaborated manner.

Use case diagram

Use case model – Access to car parking

Design Activities

• Database Management System

Database engine that would be used in this case would be MySQL database and there will be numerous advantages of this system that will be offered to the information and control system for XYZ car park. The information would be easily stored and managed and there will also be enhanced security features that will be involved with the use and application of MySQL in the back end.

• Environment

The team members that will be engaged in the information and control system for XYZ car park would require the technical environment to carry out several activities related to the project such as design and development. Testing is an important activity that would be required to be fulfilled and carried out by the project resources and the activity would demand the testing environment from the project. It would also be essential to test the system in the environment that would be close to the real system and therefore a production environment would also be necessary.  

• Navigation

It would be essential to ensure that the system that is developed for XYZ car parks is easily accessible and can also be smoothly navigated. The problems in navigation would bring down the levels of customer satisfaction and therefore it would be essential that the navigation that is offered with the system can be carried out with much ease. 

• Layout and themes

The car park system that would be designed for XYZ car parks would be used by various entities from the operational and management staff. Some of these entities will be technically sound while there will be some that would have less experience with automated information systems. The layout shall therefore be selected in such a manner that the needs and ease of usage is catered and provided to all the users. Also, there shall be no use of excessive colors in the system and simplicity shall be maintained and followed (Stanford, 2016). 

• Software Methods

There are numerous software methods and methodologies that may be used in the design of the car park system. The methodology that would be apt and would fit in this case would be agile methodology as it would provide the project resources with the required framework and would also provide them with the ability to stay in close contact with the client at all times (Szalvay, 2016).

System Vision Document

Problem Description

There is a lot of traffic that is experienced by the car parks on a daily basis in terms of the vehicles that enter and exit from the car park. There are problems that are encountered in terms of the performance of the system and the experience of the customers (Legunsen, 2016).

System Capabilities

The system that will be designed for XYZ car park will have the ability and capability to handle the vehicles that enter the car park and provide the necessary parking space as per the customer type. It would offer enhanced operational and management abilities to the resources and users and there would be functionalities installed and set up in terms of entry, exit, payment, fault recording, management and security management.

System Benefits

The system will offer numerous advantages which are as listed below.

• Performance that would be showcased by the system would lead to enhancement of customer experience and engagement
• The system will provide a competitive edge to XYZ as it would perform better than the rest of the peers in the market
• The level of customer trust will also improve
• There will be lesser frauds and errors that will be encountered with the installation of an automated system

Work Breakdown Structure (WBS)

Conclusion

System design and system architecture are necessary for the success of the system and the case is the same with XYZ car parking system. There are several functional and non-functional requirements that are associated with the system in terms of operations and management areas which shall be reflected in the system design. Also, the design and architecture shall be in accordance with the design principles and the methodology as agile framework. It will offer many advantages to the system in terms of its scalability along with the performance and quality. 

References

Brandenburg, L. (2016). What Goes Into a Functional Specification?. Bridging-the-gap.com. Retrieved 30 April 2017, from https://www.bridging-the-gap.com/functional-specification/

Gomaa, H. & Olimpiew, E. (2016). The Role of Use Cases in Requirements and Analysis Modeling. Retrieved 30 April 2017, from https://www.ie.inf.uc3m.es/wuscam-05/5-WUsCaM.pdf

Ibm,. (2016). IBM Knowledge Center. Ibm.com. Retrieved 30 April 2017, from https://www.ibm.com/support/knowledgecenter/SSYMRC_4.0.5/com.ibm.rational.rrm.help.doc/topics/r_vision_doc.html

Ifla,. (2016). IFLA -- Functional Requirements for Bibliographic Records. Ifla.org. Retrieved 30 April 2017, from https://www.ifla.org/publications/functional-requirements-for-bibliographic-records

Legunsen, O. (2016). Vision Document. Retrieved 30 April 2017, from https://www.utdallas.edu/~chung/RE/Presentations10F/Team-hope/1%20-%20VisionDoc.pdf

Legunsen, O. & Lindee, C. (2016). Vision Document. Retrieved 30 April 2017, from https://www.utdallas.edu/~chung/RE/Presentations10F/Team-hope/1%20-%20VisionDoc.pdf

Loewy, R. (2016). Nonfunctional Requirements – Scaled Agile Framework. Scaledagileframework.com. Retrieved 30 April 2017, from https://www.scaledagileframework.com/nonfunctional-requirements/

Onedesk,. (2016). Functional Requirements vs Non Functional Requirements – OneDesk. Onedesk.com. Retrieved 30 April 2017, from https://www.onedesk.com/functional-requirements-vs-non-functional-requirements/

Patton,. (2016). IFLA -- Functional Requirements for Authority Data – A Conceptual Model. Ifla.org. Retrieved 30 April 2017, from https://www.ifla.org/publications/ifla-series-on-bibliographic-control-34

Requirementsnetwork,. (2016). Business Requirements vs Functional Requirements from RequirementsNetwork.com. Requirementsnetwork.com. Retrieved 30 April 2017, from https://www.requirementsnetwork.com/business-functional.htm

Smartba,. (2016). Functional Requirements. Retrieved 30 April 2017, from https://www.smart-ba.com/download/Module%203.pdf

Stanford,. (2016). Website Redesign Proposal. Retrieved 30 April 2017, from https://web.stanford.edu/~eadolfo/cis-redesign/attachments/proposal-newsignature.pdf

Szalvay, V. (2016). An Introduction to Agile Software Development. Retrieved 30 April 2017, from https://www.danube.com/docs/Intro_to_Agile.pdf