HTW Berlin Fachbereich 4 Internationaler Bachelor Studiengang Internationale Medieninformatik (Bachelor) Informatik 3 Winter Term 2023/24
	Info 3: Informatik III Modern Software Engineering

Your job Your job over the course of the semester will be to design a system for helping grocery store owners find the shopping carts that selfish customers have taken from the store and left somewhere in the neighborhood. We will not be implementing the system, just designing it. You are, however, free to implement this over the break and make money off of the idea if you can. The company that sells the shopping carts is already working hard on the problem. You need to form a team of three to four people. You will be working together for the rest of the semester. Choose a team name, if you wish. Printing team T-Shirts is optional. This exercise spans two weeks. The first week you need to form your team and start by preparing user stories. Begin thinking about the project, but don't start your diagrams until the second week. Lab reports are only due for the second week, the day before the next exercise. Each team will submit a core report that should be the same for all members of the team and includes a personal reflection of each team member on what they learned in this exercises and states the amount of time (in and out of class) spent on the exercise.

User Stories

A user story is the result of the first steps a developer takes in trying to understand the requirements that a system needs to fulfill. It is rather informal, although there is a basic structure to the stories. Natural language is used, and they are all written from the perspective of the user, not the developer. We are not thinking in solutions yet, but trying to understand the problem.

There are a few templates that are traditionally used to write user stories.

	As a <role> I can <capability>, so that <receive benefit>

	In order to <receive benefit> as a <role>, I can <goal/desire>

	As <who> <when> <where>, I want <what> because <why>

They represent the business case for the development. There is still a lot missing, but they are very useful for getting a discussion going, which is why some people call them a "promise for a conversation".

Use cases and Scenarios

Use cases are a scenario-based technique for requirements elicitation. They were first proposed by Ivar Jacobson as part of his Objectory methodology. There are many different variations on use cases floating around, but the basic idea is to record the situation in which something happens in the system that involves interaction with the outside world. The actors on the outside are named, and a formalized method is used to explain what should happen, and describe any exceptional circumstances which might arise.

In a scenario you describe a concrete use of the proposed system, using the names of a proposed user. In the use case we then abstract away from the concrete situations given in the scenarios and try and describe a more general case. We have user roles and system functionality, which are depicted in diagrams as little stick figures and circles, respectively:

An actor is something or someone that interacts with the target system to produce an observable result. There are active and passive actors. They are usually drawn with a stick figure, although I sometimes enjoy using a stick-woman figure just to be ornery.

A use case is an instance of how an actor would use a software system or a service offered by the system. More than one actor can participate in a use case. We draw use case diagrams to visualize the use cases and write out the use cases using templates, such as the one given in Wikipedia. Use case diagrams are decorated with the name given to the use case.

A scenario will typically describe the sequence of concrete activities that happen when a user is interacting with the proposed system. It is a detailed, step-by-step description of observable behaviors—that is, it does not describe the internal workings of the machine, but what a user can observe from the outside. We are not worried right now about how it will be done on the inside, but instead just want to see if the use of the system makes sense.

We can branch inside a scenario using an if statement and can repeat steps using a while statement. A scenario will not have exceptional conditions. If it is describing one such exceptional interaction, then it explains each step of what happens. A scenario also does not extend another scenario—it just describes what happens in this concrete instance.

We give names to scenarios and use cases, so that we can talk about them. The name should somehow be connected to the use case it is describing. Then we describe any precondition that must hold before the scenario can commence. For example: The user has a valid EC card. Then the sequence of steps is listed, followed by a postcondition describing what must hold at the end of the scenario. For example, the account linked to the EC card has been debited by 100 Euros and the user now has 100 Euros cash in her hands and the card is now marked as having been used on the current day.

There are also scenarios sometimes referred to as "secondary scenarios" which describe alternate paths. They have their own name, the name of the scenario to which they are referring, and a description of the problem or alternative faced.

A number of scenarios are usually collected and abstracted into a Use Case and expressed graphically by a Use Case Diagram. The elements of a Use Case often include:

1. Name of the use case
2. Summary
3. Actors involved
4. Basic sequence of steps
5. Alternate sequence
6. Exceptions that can occur
7. Extension points
8. Trigger
9. Assumptions
10. Preconditions
11. Postconditions
12. Author and Date

You should realize that every author and every company have their own ways of describing Use Cases, but usually each of these aspects are addressed.We will be using the structure given here.

Our case study

You have surely seen them, they are all over Oberschöneweide and pretty much everywhere else in the city: abandoned shopping carts. Lazy customers steal them from grocery stores or hardware stores to cart their purchases home, usually because they don't have a car or bought too much to carry. Instead of returning the shopping cart when it is empty so that others can use them to shop, they are often abandoned in front of the house on the sidewalk. They collect garbage thrown in by passers-by or just stand in the rain. Youth use them for joy-riding. Sometimes brave souls return the carts, often getting nasty looks from patrons waiting outside for a free cart, as they assume the honest returner is the thief. Our case study is to propose a solution! Random people should have an app on their phones so that they can take a picture of an abandoned cart, automatically obtain the geo-location, and have it stored in a database. If people register, they should be able to collect some sort of stars or points. A leaderboard will display the top returners of the month. Of course, there will be multiple people informing about the same cart, and often there are multiple carts at the same location (just walk down the Edisonstr. from Aldi on pretty much any random day to have a look). And of course, there will be carts from different stores at the same location.

Grocery store owners can register for the service, too. They should be able to specify a radius around their store that they want to search for carts from their store. After all, the things cost a lot of money! They only want to find their own carts, not those of other stores. They want to print a list of nearby carts and have them located on a map so that they can send someone out to collect them when there not much to do.  Even though the system is planned for Germany, there should be a possibility of using other languages, at least English, Turkish, and Polish, with the system. Administrators are responsible for setting up and maintaining the system. And there are perhaps statistics that need to be kept.

Exercises

1. Your job during the first week is to write user stories for this case study. Who are the stakeholders and the actors in such an application system? They will need names and a description of their role. Is there anything missing in the description of the case study? Why would the actors want to interact with this system? What's in it for them?
2. Now each member of the team develops at least three scenarios. That means at least 9 scenarios for a 3-person-group, at least 12 for a four-person group.
3. From the scenarios now develop some use cases. Which actors are involved with which use case? Give the use cases good names and describe them using the format above. There may be more use cases than scenarios.
4. Draw appropriate use case diagrams with any UML tool to show how your actors communicate in the use cases. Try to generalize from some concrete situations, what is the common part? Can you perhaps even define an inheritance hierarchy, that is, there is a general, a sort of "super" use case that has specialist use cases? Fix the use case diagram to reflect this! We use arrows between the use case ovals to denote this. Look up the syntax on the web and include the URL of where you found it in your report.

There is a forum for submitting exercises in Moodle—please have your exercises online here by 23.59 the day before the next exercise. Please include all materials (scenarios, use cases and use case diagrams) in one PDF and don't forget to put the names of each person involved on the report. Each person needs to include a personal reflection on what they learned and how difficult they found the exercise. Everyone in the group submits the same PDF. Alternate formats such as ZIP files will be considered not submitted.