Use Case vs User Story

A Use Case typically includes several elements:

1. Actors:
   Actors represent roles or external entities that interact with the system. These can be users or other systems or devices. An actor plays a specific role in a use case. For example, in an online ordering system, an actor might be “Buyer” or “Administrator“.

2. Preconditions:
   Preconditions describe states and conditions that must be met before a use case can begin. They define what state the system must be in before the use case can begin. For example, a precondition for an order placement scenario might be:The user must be authorized in the system.“.

3. Main stream:
   The main flow describes the sequence of steps that must be completed to achieve the goal of the scenario. It is the main path that the user follows in a typical situation. For example, for a product purchase scenario, the main flow might include the following steps: product selection, adding product to cart, Entering payment data And confirmation of an order.

4. Alternative streams:
   Alternative flows describe possible deviations from the main flow that may occur during the execution of the scenario. These may be options for user or system actions that lead to the successful completion of the scenario. For example, if the selected product is out of stock, the system may offer the user to select another product.

5. Postconditions:
   Postconditions describe the state of the system after the use case has completed. They indicate what changes should occur in the system after all steps of the use case have completed. For example, a postcondition for an order placement scenario might be:Order information is saved in the database“.

6. Exceptions:
   Exceptions describe errors or unexpected situations that may occur during the execution of a scenario. These scenarios define how the system should react to such events. For example, if an error occurs while processing a payment, the system should notify the user and offer to try again.

Example Use Case:

Name: Placing a purchase order

Actors: Buyer

Preconditions: User is authorized on the site

Main stream:

1. The buyer selects the product.

2. Adds a product to the cart.

3. Proceeds to checkout.

4. Enters data for delivery and payment.

5. Confirms the order.

Alternative Streams:

• If the product is out of stock, offer to choose another product.

• If the shipping address is not supported, please ask to enter another address.

Postconditions: The order has been created and confirmed, the order information has been saved in the system.

Exceptions: If an error occurs while processing a payment, notify the user and offer to try again.

User Story

A User Story is a short, informal description of the functionality of a system from the perspective of an end user or stakeholder. User Stories are often used in Agile development because they help focus on user needs and provide flexibility as requirements change.

User Story Template:

A User Story is usually written in the format:
“How <роль>, I want <действие>, to <цель>.”

This template allows you to understand who the user is, what he wants to do and why he needs it.

Key elements of a User Story:

1. Role:
   Refers to the user or stakeholder who will interact with the system. For example, this could be “registered user” or “administrator“.

2. Action:
   Describes what the user wants to do. This action should be clear and specific. For example, “add product to cart” or “create a report“.

3. Target:
   Indicates the reason or benefit the user will receive by performing the action. This helps to understand the user's motivation and end goal. For example, “to then place an order” or “to analyze the data“.

Example of User Story:

Role: Registered user

Action: Add product to cart

Target: To then place an order

So the user story might look like this:
“As a registered user, I want to add a product to my cart in order to place an order.“

For complete clarity and accuracy, User Stories may also include:

• Acceptance criteria:
  Conditions that must be met for a user story to be considered complete. For example, “The product is added to the cart only if it is in stock.“

• Notes:
  Additional information or comments that may be useful for understanding the context or details of the user story.

One more example:

Role: Site administrator

Action: Create a sales report

Target: To analyze monthly sales and make decisions on product range

User Story: “As a site administrator, I want to create a sales report to analyze monthly sales and make decisions on product range..”

Acceptance criteria:

1. The report includes data for the specified period.

2. The report can be exported in CSV format.

3. The report displays data by product categories.

Notes: The report should be generated in no more than 30 seconds.

Comparison

Use Case is best suited for complex projects with multiple interactions and strict regulatory requirements. For example:

• Systems with a high degree of integration with other systems or devices.

• Projects requiring detailed technical documentation to comply with regulatory or safety standards.

• Complex business processes that require a complete description of all possible scenarios and interactions.

User Story is good for projects with frequent changes in requirements and the need for close interaction with customers. Examples:

• Projects using Agile or Scrum methodologies, where flexibility and adaptability are the basis.

• Rapid MVP development to test ideas and get feedback from users.

• Teams working closely with customers and stakeholders, requiring a fast and flexible approach to change.

Sometimes teams use a hybrid approach, combining features from both methods. For example, a User Story for initial assessment and definition of high-level requirements, and then moving to a Use Case to work out complex scenarios in detail.

In conclusion, I would like to invite everyone to open lessons that will soon be held as part of the online course “Business Analyst in IT” in Otus:

• July 9: Formation of conceptual schemes of the subject area. Let's talk about the description of the subject area in terms of the composition of objects and their interrelationships. Registration via link

• July 22: Business processes as a tool for immersion in the subject area. We will focus on business process modeling. We will consider examples of BP schemes, discuss frequently occurring errors and their impact on the course of the project/product development. Registration via link