This is the main page for our collection of use cases.
To add a new one please insert a suitable name and then click "Create Use Case" to launch a new page for your entry. Then fill in the missing sections of the template.
- 1 Why Use Cases?
- 1.1 Use Cases by Category
- 1.2 Use Cases by Action
- 1.2.1 Actions for the Display of Examples
- 1.2.2 Vacancies
- 1.2.3 Actions for the Differentiation of an Offer
- 1.2.4 Booking Actions
- 1.2.5 Actions for the Display of a Reservation
- 1.2.6 Actions for the Modification of a Reservation
- 1.2.7 Payment Actions
- 1.2.8 Actions for Printing of Vouchers
- 1.2.9 Display of Reservation Lists
- 1.2.10 Information
- 1.2.11 Test Actions
- 1.2.12 Service Actions
- 1.3 Use Cases by Reference to Request Document
Why Use Cases?
We aim to create a complete replacement for all transactions which are handled by STADIS and many external extensions today. To do so we have to find out which transactions are needed and what kind of data is exchanged between clients and tour operator systems.
So for a start every action code used today in TOMA-like systems should have at least one assigned use case here (or be deprecated).
The same applies for all proposed extensions of the "Anforderungsdefinition".
See Flight Availability (Gerätevakanz) for an example of what we need.
Use Cases by Category
Handling: Booking administration
Use Cases by Action
The STRING interface will not use action codes but request/response pairs. We aim however to support all methods of the old interfaces we're superseding as long as they are not deprecated or applicable.
Several action codes might be linked to the same use case when their functionality will be bundled into the same request/response.
Actions for the Display of Examples
- G Flight Availability (Gerätevakanz)
Actions for the Differentiation of an Offer
Actions for the Display of a Reservation
Actions for the Modification of a Reservation
Actions for Printing of Vouchers
Display of Reservation Lists
- +/- (Paging)