[options="header"]
[cols="1, 3, 3"]
|===
|Version | Bearbeitungsdatum   | Autor 
|...	| ... | ...
|===

= Entwicklerdokumentation


== Introduction and Goals

== Task Definition

As our client Mr Wurst has built up the large catering service Mampf over the years, he now needs a system that will simplify planning for him and his customers. The catering service should enable him to process all billing, ordering and administrative tasks in a standardised way. Previously, Mr Wurst used various programmes for this and was always annoyed by their incompatibility with each other and the additional work involved in separate data storage. He gave us the following description of his small company as a basis for the system development:

The company is divided into four business areas. Event catering provides catering for large events, whether in the form of a buffet or a gala dinner. On request, Mampf can also organise the entire event, i.e. in addition to the food and drinks, decoration, equipment (i.e. crockery, tablecloths, etc.) and staff are also provided, whereby the customer must of course pay rental fees and staff costs in addition to the actual price for food and working hours. The party service supplies private celebrations with cold platters - from weddings and funerals to garden parties and grandma's 75th birthday. There are fixed prices depending on the offer and number of people (e.g. ham platter for 5 people at EUR 20, cheese platter for 3 people at EUR 12.50, etc.) and special offers (e.g. sushi evening for 10 people). A speciality of Mampf is Mobile Breakfast - a mobile breakfast service for smaller companies without their own canteen. Employees can buy a selection of breakfast options (sandwiches, muesli, coffee and tea, etc.) at their workplace at set times. The companies book the offer on a monthly basis. However, planning this offer is problematic - a cost-saving solution (e.g. in the form of pre-ordering) is currently being sought. Mampf's fourth offer is also becoming increasingly popular with customers: Rent-a-Cook. This involves hiring out kitchen and service staff to private households, for example to impress the host's boss with culinary delights. Customers have to take care of the food themselves.

The most important functions that the system should include are to support customer management, take over staff management and allocation, plan appointments, manage accessories (decoration, equipment), determine food requirements (number of dishes/plates/served sandwiches, quantity of drinks in litres), simplify invoicing to customers and facilitate all billing. However, food procurement does not have to be considered. In the end, the catering service should be fully functional and include all the functions already mentioned. The aim is to use centralised data management to make processes more efficient, especially planning within the company. The system should be easy to expand in order to open up new business areas.

The client made the following statements verbally on request:

Customers must be able to register themselves, book orders and delete their account if necessary. The latter should also be possible for the administrator for any customer. The administrator also has special overview pages for managing the business. Orders can only be paid for in cash. The allocation of resources to an order must take place without manual intervention. As part of the special promotions mentioned above, certain offers should have a promotional price and be specially labelled. Bookings for Mobile Breakfast are made on a monthly basis at fixed time slots. There are several menus to choose from. Invoice means an informal list of order items in PDF format and on the website. Billing refers to an informal statement of the actual hours worked by employees each month. In technical terms, passwords for user accounts should be stored securely in accordance with current standards.

== Quality Demands

Functional Suitability::

This characteristic represents the degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions.

Performance efficiency::

This characteristic represents the performance relative to the amount of resources used under stated conditions.

Compatability::

Degree to which a product, system or component can exchange information with other products, systems or components, and/or perform its required functions while sharing the same hardware or software environment

Usability::

Degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

Reliability::

Degree to which a system, product or component performs specified functions under specified conditions for a specified period of time.

Security::

Degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization

Maintainability::

This characteristic represents the degree of effectiveness and efficiency with which a product or system can be modified to improve it, correct it or adapt it to changes in environment, and in requirements.

Portability::

Degree of effectiveness and efficiency with which a system, product or component can be transferred from one hardware, software or other operational or usage environment to another.

The following table shows what quality demands have to be fulfilled to which extent.
The first column lists the quality demands, while in the following columns an "x" is used to mark the priority.

1 = Not Important ..
5 = Very Important
[options="header", cols="3h, ^1, ^1, ^1, ^1, ^1"]
|===
|Quality Demand           | 1 | 2 | 3 | 4 | 5
|Functional Suitability   |   |   |   |   | x
|Performance efficiency   | x |   |   |   |
|Compatability            | x |   |   |   |
|Usability                |   |   |   | x |
|Reliability              |   |   |   | x |
|Security                 |   | x |   |   |
|Maintainability          |   |   | x |   |
|Portability              | x |   |   |   |
|===

== Constraints

Each constraint is annotated with b, r and/or u,
each representing if it is a
build-time (includes development),
run-time (backend),
or use-time (frontend)
constraint.
Use-time constraints can be separated into customer (c) and administration (a),
each denoted by having their letter prefixed with `u.`.

=== Hardware Specifications

 * r: server computer
 * b: mid-range computer
 * u: computer
 * b: input device for text
 * u: input/output devices
   ** pointing device
     (e.g, mouse, TrackPoint™, digitizer, touch input)
   ** text input device
     (i.e. keyboard),
     can be emulated (software/touch or for accessibility reasons)
   ** u.a: screen with a resolution of at least 1920×1080 at a DPR of 1 (= 96 dpi)
   ** u.c: screen with a resolution of at least 360×640/640×360 at a DPR of 1 (= 96 dpi)

=== Software Specifications

 * r: JRE 17
 * b: JDK 17
 * u: Any HTML5/CSS3 compatibly browser using one of the following engines (or a newer version)
   ** Chromium 108
   ** Firefox 115
   ** WebKit 605.1.15
   ** Explicity not supported are any browsers based on Trident/EdgeHTML

=== Product Usage

The system is going to to be used as a website for administration and handling of orders for the catering service operated by Hannes Wurst.

The system is supposed to run on a server computer
(a computer running 24/7 with a datacenter-grade internet connection)
so that customers and the administrator can access it at any time.
Its provided service is made available as a web site (HTML5/CSS3/ECMAScript over HTTP).
Should the customer of the project require an encrypted connection using TLS,
it is their responsibility to set up a reverse proxy in front of the system.

It cannot be assumed that the users (customers and administrator) have a technical background,
so common patterns that are easily learned should be used.

== Kontextabgrenzung
* Kontextdiagramm

== Lösungsstrategie
=== Erfüllung der Qualitätsziele
[options="header"]
|=== 
|Qualitätsziel |Lösungsansatz
|... |...
|===

=== Softwarearchitektur
* Beschreibung der Architektur anhand der Top-Level-Architektur oder eines Client-Server-Diagramms

=== Entwurfsentscheidungen
* Verwendete Muster
* Persistenz
* Benutzeroberfläche
* Verwendung externer Frameworks

[options="header", cols="1,2,3"]
|===
|Externes Package |Verwendet von |Warum
|... |... |...
|===

== Bausteinsicht
* Package-Diagramm
* Entwurfsklassendiagramme der einzelnen Packages

[options="header"]
|=== 
|Klasse/Enumeration |Description
|... |...
|===

=== Rückverfolgbarkeit zwischen Analyse- und Entwurfsmodell
_Die folgende Tabelle zeigt die Rückverfolgbarkeit zwischen Entwurfs- und Analysemodell._

[options="header"]
|===
|Klasse/Enumeration (Analysemodell) |Klasse/Enumeration (Entwurfsmodell)
|... |...
|===

== Laufzeitsicht
* Darstellung der Komponenteninteraktion anhand eines Sequenzdiagramms, welches die relevantesten Interaktionen darstellt.


