Instructions on Phase P3: Application Scenarios for DB Access (SQL)

In this task, you need to define the main use cases of the imagined application and the proposed usage scenarios and how the implemented database will be used in each scenario.

Actors are the roles that different people assume when using the system. It is possible for a user to work under multiple roles or act as different actors, if they are assigned to several different jobs, but each user can also have only one role. Roles are usually called actors. For example, in a supermarket system, the following actors may appear: Customer, Cash register worker, Information desk worker, Warehouse Worker, … Keep in mind that one person act as in several roles - if in the morning one had the role of a warehouse worker when receiving goods, then one can became a cash register worker when the supermarket opens and customers come in, and in the afternoon, before going home, one can become a Customer to buy some supplies for their personal use. The official job position is not always related to the role, as the same person can be the sole owner and employee of the supermarket, so his job is the director or owner. So the roles arise from what work is being performed at the moment and then the role can change, and do not arise from the jobs of the people. Actors are: either people who use the system or other systems that your system will call for some work (for example, a system for checking the balance of a credit card when making a purchase). There is no actor called the System, because only third-party systems can be actors, do not even try to put your system as an actor. There is no actor called User, because all actors are users, come up with more appropriate names.

Imagine different usage scenarios where the system is used by different actors. As an example, when someone acts as an actor, there is some ultimate goal that they want to fulfill. For example, one becomes a warehouse worker in order to receive and enter all the goods that have arrived into the system that day, so that they become available to customers. We are interested in all such larger goals that are of importance (for example, receiving the received goods and entering them into inventory for sale), and not micro goals (for example, entering the price of the first product received, entering the name of the third product received).

Create a wiki page called UseCaseModel and use the structure from this template:

Use-case model

List of Actors / Roles

• Actor name - Short description in one sentence List Use-cases where the actors is the initiator of the work
  • UCxxxx (where xxxx is the number of the use-case) - Use-case title - One sentence description
  • …
• …
  • …
• …
  • …

Use-case model diagram (optional}

Presenting a Use-case model diagram that includes all the actors and use-cases is optional, but highly beneficial for the project.

Realization details on selection of the most important use cases in the database

Select which of the listed use cases are the most important in your application and are essential for the application to document in more details. Choose at least one scenario for each of those use-cases. You should cover at least 3 use cases per team-member, with at least 1 scenario in each. Each team member should have at least one use case with a database usage scenario.

Document in more details the selected use-cases that you deem are most important for the system. Document the use-case details in the so-called dialog form, where you details all the interaction steps between the actor and the system (example: 1. user chooses option, 2. system shows form, 2. user enters data in form with details on all the data that are entered, 3. system checks validity, 4. user submits form, 5. system opens a new screen listing the results of the database operation, 6. user chooses among the data to view more details, 7. system shows more details, …). If you deem valuable to present a sketch of the application screens in each step, please do attach them (even napkin level sketches are fine).

The scenarios should detail on everything that needs to happen to reach the final goal of the actor. When some of the scenario steps modify or show data from the database, write SQL commands that will extract the needed data from the database or the SQL commands that are needed to modify the database. Show real SQL commands that were tested to work in the created database in the previous phase.

Create a new wiki page for each of the selected use-cases, with wiki names UseCaseXXXX (where xxx is the number of the use-case), and link them in the list of use-cases in the use-case model wiki page. Use the following short-form template, you do not need to fully document the use-cases with all details that are standard for use-cases.

Use-case XXXXX - Use-case title

Initiating actor:

Other actors:

Description of the use-case goals in several sentences.

Scenario:

1. User does what.
2. System does what. If the system access database, include the exact SQL command to detail what data will be needed from the database, or what data will be modified in the database. Show real and tested SQL commands.
3. …

AI Use

You are free to use an AI to improve your modeling, provided that you adhere to the following rules:

• you use AI in this phase of the project only to improve your own initial model
• you use AI to create an alternate model for ideas that you can borrow and use in your own model
• you document the changes you have made to your own model based on the ideas from the AI tool in the model history above
• you document the entire usage of the AI tool in a new wiki page named UseCaseModelAIUsage linked here, that you structure according to the following template

Use-Case Model AI Usage

Name of AI service/solution that was used

URL:

Type of service/subscription:

Final result

Diagram:

Results in details / description:

Entire AI usage log

1. Line-by-line Log of all interactions with the AI (prompt and response)
2. …