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

Santeri Viinamäki, CC BY-SA 4.0, via Wikimedia Commons

Your job Your job over the course of the semester will be to design an app that will help shoppers on a budget buy groceries as cheaply as possible. The app is to be privacy-preserving, that is, data is only to be stored locally on the app, not in some cloud or even with a store. This is what makes it different from all the store apps that are around, they want to have your data and shopping lists. You need to form a team of about 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 blocks.  Each team will submit a 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. The report is due next week at 22:00.

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. User stories describe features the product should have, user requests that have been made, needed development activities, or engineering improvements.

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 use case 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

Times are rough. Inflation is high, shrinkflation is worse, people on a budget have it very hard to do their shopping. They may have to study 5 or 6 different store flyers to see where the specials are and make more than one shopping list so that they can get their food as cheaply as possible. There are different things people want the app to do. They might want to set a budget limit for each shopping tour and as they check items off their list, they enter the price (or scan it?) and have this deducted from their limit so that they don't have to go through the shame of having to put back an item at the cash register.   They also will want to make a master list of items that they need, but would like to have the app compare prices for them. They would like the app to ask around their neighboring stores what the prices of various items are. Depending on the answers they would put that item in a separate list for that particular store. There should probably be some sort of calculator integrated. And maybe people want to keep a record of what they bought in the past month. Or even calculate (and store?) the unit price of their favorite items. Your task is to propose a solution!  Feel free to be adding functionality as necessary, this is only a sketch of what the app could be. We will NOT be programming it this semester, only specifying it. That is the focus of software engineering.

Bruce Turner from AustinTX, CC BY 2.0, via Wikimedia Commons

Exercises

1. Your job is to write user stories for this case study. Who are the stakeholders and the actors in such a product? 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 an area for submitting exercises in Moodle—please have your exercises online here by 22:00 of the next week. 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.