Osz oberstufenzentrum handel 1 computer science sample database flotter flitzer

Osz oberstufenzentrum handel 1 computer science sample database flotter flitzer

The "Flotter Flitzer" car rental company specializes in the rental of luxury sports cars. This type of car forms the main offering, but mid-range cars are also loaned out.

Now the administration is to be changed over to EDP. A relational database is envisaged, which will initially be used to handle rentals and the administration of the vehicle fleet (details of the vehicle type and documentation of repairs).

Requirements for the users

In the processing of the Lending two areas of work are to be distinguished:

The loan: Here the personal data of the customers, the issued cars and the mileage are recorded. The return: The registration of the returned cars and the mileage.

For the Administration of the vehicle stock is also to be set up in two areas:

The car management: Here the passenger cars are recorded or. Deregistered. The documentation of the repairs. The management of information on the workshops.

All areas must have access to all the information necessary for the performance of their respective tasks. The data and system maintenance remains with the system administration.

The permission to make deletions is regulated as follows:

– Customers and cars may only be deleted by the system administrator. Manufacturers are allowed to-. System management can be deleted. Workshops are allowed by the system management. The maintenance to be deleted. – No one is permitted to delete data relating to the loan and repair.

Requirements for the mode of operation

No EDP experience can be drawn on from the employees of the car rental company. Use must therefore be as simple and error-tolerant as possible. Online help must be included for the essential points. Inputs must be designed in such a way that fast, error-free entry is possible even in hectic mass operations.

Requirements for the scope of services

The rental service is to use the program to register customers and assign them a car, including entering the current speedometer reading. All borrowing operations are numbered automatically. When the car is returned, the return date. The current tachometer reading recorded.

As data of the clientele name, address, date of the driver's license acquisition and date of birth are stored obligatorily. For the passenger car are obligatory license plate, manufacturer with name, address and contact person, model with name, power, engine capacity, air conditioning, sunroof, length and width and the date of first registration recorded. Only new vehicles are procured directly from the manufacturer. If cars are removed from the fleet, only the deregistration is entered into the database. The car will only be completely deleted at the end of the fiscal year.

From the workshops name, address and contact person are stored. The repair data to be provided are the registration number of the relevant car, the name of the workshop, the date of repair and the type and duration of the repair.

In order to prevent manipulations, all procedures are to be logged. The log file may only be viewed by the system administration and may not be deleted by anyone.

The fiscal year is the calendar year. At the end of each fiscal year, all ongoing data, in this case all completed rental and repair transactions, are removed from the database and stored on a magnetic tape for tax purposes.

Requirements for possible expansion stages

In the first stage of expansion the financial transactions are not recorded. As a further stage of expansion, the processing of all payment transactions should be included.

Also the administration of the personnel is to be realized in a later expansion stage.

Requirements for error behavior

To ensure smooth operation, incorrect entries are to be rejected as far as possible. Also, incorrect operation must not lead to a crash of the system. Not lead to data loss in the first place. In the event of an error, meaningful, context-sensitive online help should be provided.

Quality requirements

The aim is to create a program system that is as error-free and easy to maintain as possible. The program is to be transferred with little effort to other hard-. Software platforms can be transferred. Therefore, it is necessary to use manufacturer-independent standards as far as possible.

Data protection requirements

The customers are informed upon conclusion of the contract that their data will be stored electronically for the purpose of processing the rental. A passing on of the data to third parties is excluded.

Ergonomic requirements

The program should be as ergonomic as possible. This applies in particular to the rapid entry of data at the check-out desk. All masks are to be designed uniformly. The screen forms should be filled in with. The structure of the existing paper templates must be identical. All screens should contain at least information about the location in the program, how to leave the screen and how to cancel it.

Documentation requirements

The structure of the program, including the used data structure, the masks and the commented program listings are documented in a maintenance manual. The system should be designed so user-friendly that no manual is necessary.

Requirements for the basic machine

The system should be able to be implemented on current computers regardless of operating system. It would be desirable to be able to perform maintenance via the Internet using common browsers.

Like this post? Please share to your friends:
Leave a Reply

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: