Scribd
Upload
50 views

"Software Engineering" Assignment 4 "Use Case Descriptions and Diagram"

The document describes several use cases for a recipe generation mobile application: 1. Users can sign in with an email/username and password. They can also sign up to create a new account. 2. Users can enter ingredients which are verified against a database. They can then generate and save recipes based on the ingredients. 3. Additional use cases allow users to rate and share recipes with others, and change application settings.

Uploaded by

Hassnain Abbas
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
50 views

"Software Engineering" Assignment 4 "Use Case Descriptions and Diagram"

The document describes several use cases for a recipe generation mobile application: 1. Users can sign in with an email/username and password. They can also sign up to create a new account. 2. Users can enter ingredients which are verified against a database. They can then generate and save recipes based on the ingredients. 3. Additional use cases allow users to rate and share recipes with others, and change application settings.

Uploaded by

Hassnain Abbas
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

“Software Engineering”

Assignment 4
“Use Case Descriptions and Diagram”

Submitted By
Zain Ul Abiddin 21-BSCS-15
Mueed Sajjad 69-BSCS-15

Submitted To:
Dr. Adnan Khalid
➢ Use case: Sign In
Primary Actor: App user
Goal in context: To gain access to the application.
Precondition: The user must have an account to log in to.
Scenario:
• The app user opens the app.
• The app user enters his email or username.
• The app user enters his password.
• The app user presses the sign in button.
Exceptions:
• The user does not have an account to login to.
• Wrong email or password entered.
• The user does not have an active internet connection.
Priority: Essential
When available: First increment
Frequency of use: Just once for logging in. This function won’t be required
until the user has signed out from the app.
Open issues:
Can a user access the application without having an account?

➢ Use case: Verify email/password


Base case: Sign In
Goal in context: To check if the email and password entered by the user
are correct.
Precondition: The user has entered an email and a password.

Scenario:
• It takes in the email or username and matches with the already stored
username.
• It takes in the password and matches with the already stored user
password.
Exceptions:
• Misspelled username or password.
Priority: Essential
When available: First increment
Frequency of use: When sign in use case is executed then this use case is
always executed.

➢ Use case: Display login error


Primary Actor: App user
Goal in context: To display a login error message if username or
password is incorrect.
Precondition: User has entered his username and password.
Scenario:
• The user enters his username.
• The user enters his password.
• The user tries to sign in using the information he provided.
Exceptions:
• Wrong information provided by the user.
Priority: Essential
When available: First increment
Frequency of use: Everytime user enters wrong username or password.

➢ Use case: Sign Up


Primary Actor: App user
Goal in context: To make an account of a user so that he can access the
application.
Precondition: The person does not have an already existing account.
Scenario:
➢ The user opens the app.
➢ The user clicks on the sign up option.
➢ The user fills in all the required information.
➢ The user clicks enter.
Exceptions:
➢ The user already have an account registered before on the same email
address.
➢ The user enters his wrong personal information.
Priority: Essential
Frequency of use: Once in lifetime to access the application.
Secondary Actor: User profile

➢ Use case: Enter ingredients


Primary Actor: App user
Goal in context: To let users put the ingredients of their choice to make a
recipe out of it.
Precondition: User must know the name of the ingredient in English.
Scenario:
• User puts the name of the ingredient.
• User selects the matching ingredient from the drop-down list.
Exceptions:
• The user enters something which is not an ingredient.
Priority: Essential
When available: First increment
Frequency of use: Every time a user wants to generate a recipe out of
some ingredients.

➢ Use case: Verify ingredients


Base case: Enter ingredients
Goal in context: To check whether the correct ingredients have been
entered by the user i.e the ingredients do exist or are in
the data base.
Precondition: The user has entered some ingredients.
Scenario:
• It matches the ingredients that are already present in the database.

Exceptions:
Misspelled names of ingredients.
Priority: Essential
Frequency of use: Every time base case is executed then this use case is
also executed.

➢ Use case: Generate recipe


Primary actor: App user
Goal in context: To view a recipe for some food as requested by the user.
Precondition: The user has put in some valid ingredients.
Scenario:
• The user enters the items of his choice.
• The user clicks on the generate recipe button.
Exceptions:
• Items entered by the user were not correct.
Priority: Essential
When available: First increment
Frequency of use: Every time the user wants to generate a food recipe.

➢ Use case: Rate recipe


Primary actor: App user
Goal in context: The user can rate recipes made or shared by the other
users.
Precondition: The recipes are available publicly to be viewed.
Scenario:
• The user goes to the recipes section.
• He checks the different recipes made by different ingredients by different
users.
• The user tries it.
• The user gives it a feedback and rating.
Exceptions: None.
Priority: Not compulsory
When available: Can be made available in later increments of the app.
Frequency of use: As desired by the user.
Secondary Actors: Recipe store

➢ Use case: Share recipe


Primary actor: App user
Goal in context: Share recipes made by you to friends or share them
publicly
Precondition: You have generated a recipe.

Scenario:
• The user puts some ingredients of his choice.
• The app generates a recipe out of them.
• The user tries it.
• The user shares it.
Exceptions:
• No recipe generated by the user himself.
• Recipe generated. Tried but not upto the standard, so the user avoids
sharing it.
Priority: Not compulsory
When available: Can be made available in later increments of the app.
Frequency of use: As desired by the user.
Secondary Actors: Recipe store

➢ Use case: Save recipe


Primary actor: App user
Goal in context: The user can save the recipe generated by him.
Precondition: The user has got some recipe generated from the
ingredients that he put.
Scenario:
• The user generates the recipe.
• If the user likes the recipe then he saves it.
Exceptions:
• The user generates a recipe. Tries it and then discards it.
Priority: Essential
When available: First increment
Frequency of use: As desired by the user.
Secondary Actor: User profile
➢ Use case: Settings
Primary actor: App user
Goal in context: The user can review the app settings.
Precondition: None.

Scenario:
• The user goes into the settings section.
• Changes the theme or sets up his profile.
Exceptions: None.
Priority: Essential
When available: First increment
Frequency of use: As desired by the user.
Secondary Actor: User profile
Use Case Diagram

You might also like