Read through the problem statement and develop a first use case model. Name the actors and the use cases. We see at least two actors and three use cases. Describe each of the use cases with one sentence. Draw a use case diagram.

You may add a few more use cases, but keep the level of detail balanced and be aware that each use case produces a little extra work in task 05.

The information in the problem statement is not complete enough to determine a precise use case description. As a preparation for an interview you should therefore elaborate one complete use case description based on your understanding of the system (which might be improvable). Add two concrete scenarios for this use case. Keep in mind that the scenario should be as concrete as possible to encourage precise feedback from the stakeholders. Make sure that scenarios and use case fit together, i.e. that the use case is an abstraction of the scenario.

Take the problem statement and highlight the parts of the text that describe the application domain. E.g. “sightseeing tour” is a term from the application domain, while “persisted on the server” is a phrase from the solution domain.

Use only the text about the application domain to develop a first domain object model using Abbotts textual analysis. As a result we want to get the following:

1. A version of the problem statement text, where you highlighted the parts describing the application domain.
2. A version of the text, where you highlighted the words you found using Abbotts method.
3. A class diagram (maybe as well an object diagram) that you created by mechanically following the method.
4. A class diagram that you build upon this diagram by applying some common sense. Don't add too much! Rather focus on restructuring what you found in the previous step.

We mentioned the following classification of requirements:

• [F]unctional Requirements
• Quality Requirements
  • [U]sability
  • [R]eliability (Dependability, Robustness, Safety)
  • [P]erformance (Response time, Throughput, Availability, Accuracy)
  • [S]upportability (Adaptability, Maintainability)
• [+] Pseudo Requirements
  • Implementation requirements
  • Interface requirements
  • Operations requirements
  • Packaging requirements
  • Legal requirements

a) For a better understand of this list, we suggest that your read through the following section in [BD09] 4.3.2 “Non-functional Requirements”, Table 4-3 in 4.4.7 “Identifying Non-functional Requirements”, 4.6.5. “Identifying Non-functional Requirements” (Table 4-3 applied to an example). You can try online resources as well, but we do recommend the book.

b) Read through the problem statement again and see whether you can identify Quality and Pseudo Requirements. (Probably everything that is not a functional requirement.)

c) For each of the 4 quality and 5 pseudo requirements in our list for which you haven't found an example in b) you should suggest a sensible requirement.

Use your use case model (task 01) and your domain object model (task 03) to create an analysis object model.

Tip: We described a straightforward strategy for creating an analysis object model in the Requirements Analysis slides. See slide 51-59.