Как писать функциональные требования. Use case и user story в чем разница?

Наибольшее сходство между двумя подходами заключается в ключевых компонентах. Пользовательские истории имеют такие элементы, как роль пользователя, цель и т.д. Схожие понятия есть и у примеров использования. Они включают в себя актера, предварительные условия и другие условия. Таким образом, обе концепции схожи в том, как они подходят к проблеме.

User Story vs Use Case: Everything You Need to Know

Многие люди путают пользовательские примеры и истории, но на самом деле это разные понятия. Они могут иметь схожие функции. Например, сбор информации о требованиях и целях пользователей. Но они предназначены для разных целей. В этой статье подробно рассматриваются эти две концепции и их различия. В статье также рассматривается полезность и практичность этих двух концепций для компаний. Данная статья призвана помочь читателям и дать им представление об этой теме.

Вы когда-нибудь чувствовали, что продукт, который вы представляли себе, и продукт, который вы разработали, сильно отличаются? Или что функция, которую вы хотели, не была включена в финальную версию. Многие люди, занимающиеся продукцией, могут ответить на эти вопросы. Это может помочь понять, почему компаниям с самого начала необходим сценарий использования.

Проще говоря, пример использования — это описание того, как человек, использующий определенный процесс, достигает цели. Технически, это описание взаимодействия между системой и действующими лицами. Результатом этого процесса является документ, содержащий все шаги пользователя для достижения цели.

Пример: вы плотник и хотите изготовить дверь. Вариант использования для этого сценария состоит из всех шагов, которые плотник предпринимает для достижения цели. Вся эта документация поможет изучить недостатки и ошибки процесса.

Команды разработчиков продуктов используют сценарии использования в различных ситуациях. Он используется при планировании, тестировании и разработке. Этот процесс также помогает разработать примерный план того, как должно быть составлено руководство пользователя. В этом процессе также минимизируются ошибки и другие погрешности.

Весь процесс разработки сценария использования имеет определенные ключевые термины. Эти термины являются основой всего процесса и составляют его костяк.

1. The actor: This is the person or group of people interacting with the system. They are the users of the system.
2. The goal: This is the outcome for which the use case was designed. It is usually the final result of this process.
3. The system: This includes all the steps followed to achieve the set goal.

Эти три основных требования присутствуют не в каждом случае. Каждый проект, каждая модель и каждое обстоятельство имеют различные уровни сложности. Для сложных продуктов в сценарии использования используется множество других терминов. Некоторые из терминов таковы:

1. Stakeholders: All the parties who have an interest in the outcome of the use case. It doesn’t have to be users only.
2. Triggers: Are all the events due to which a use case begin.
3. Preconditions: It is the combination of all factors necessary for the case to occur.

Технически, сценарии использования — это подробное описание рекомендаций для разработчиков. Это дает представление о том, что разработчики включают в систему

История пользователей также является простым методом записи требований пользователей. Это помогает определить некоторые важные вопросы. Вопросы типа «кто», «что» и «почему» функции. Все эти описания служат для того, чтобы сместить акцент с написания на обсуждение функций. Это поможет упростить весь процесс и повысить эффективность.

• Main success scenarios Basic Flow – use case in which nothing goes wrong.
• Alternative paths Alternative Flow – these paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level.

What is a user story?

Важно, чтобы у истории пользователя был набросок. Для этого часто используется аббревиатура INVEST. Это помогает проверить, все ли требования соблюдены.

Теперь, когда обе концепции были подробно описаны, вам может показаться, что они одинаковы. Пересечение этих двух концепций заметно издалека, но не вблизи. Однако неизменным остается их отношение к группе товаров. И то, и другое является важной частью общего процесса разработки.

Пользовательские истории — это простой способ определить, чего хочет пользователь. Продукты могут быть четко объяснены таким образом. Хорошая история пользователя помогает всем участникам процесса понять функциональность продукта. Это также помогает проинформировать покупателя о том, что представляет собой продукт.

Это означает, что большая цель может быть разбита на более мелкие, достижимые цели. Это помогает завершить проект более эффективно и с меньшими потерями времени. Меньшие достижимые цели означают небольшое отклонение от вашей цели.

Их простой язык делает их понятными для всех. Как технические, так и нетехнические участники используют их в качестве средства общения. Это также помогает привлечь все заинтересованные стороны. Характер пользовательских историй стимулирует обсуждение продукта между различными заинтересованными сторонами.

• Independent: Not depending on other projects
• Negotiable: Room should be left for further development
• Valuable: Description of the value the end-user is going to get.
• Estimable: They should be estimated so that a proper plan can be developed.
• Small: Work should be small enough to be completed in 3-5 days
• Testable: Some mechanism to check the value delivery of the process

Четко определяя цель продукта, пользовательские истории придают смысл общей миссии. Это также облегчает команде разработчиков достижение цели. Благодаря пользовательским историям разработчики знают, зачем они создают продукт. Это помогает повысить мотивацию.

Why Create User Stories?

Это дает команде разработчиков свободу мыслить нестандартно. Затем команда может расставить приоритеты между различными идеями. Критерии приоритета могут зависеть от таких факторов, как ценность для пользователя и сложность. Это означает, что даже безумные идеи не исключены из процесса. Они могут иметь более низкий приоритет.

User stories can help to streamline the project

Рассмотрим пример приложения для аренды электромобилей.

Brings everyone on the same page

Представьте себе приложение, в котором перечислены и сдаются в аренду все варианты электромобилей в крупных городах; цель пользователей — успешно выбрать и арендовать электромобиль.

Provide a sense of purpose

Имя варианта использования: Разместить заказ на аренду.

Helps defining the whole product

Описание основного варианта использования:

Example of user story vs. use case

Альтернативный поток может быть следующим:

Как пользователь, я хочу привязать свою кредитную карту к профилю, чтобы я мог оплачивать аренду быстрее, проще и безналично.

Use case example

Как поставщик услуг, я хотел бы добавить фотографии своих автомобилей в приложение, чтобы привлечь больше пользователей.

• Shopper
• Fulfillment System
• Billing System

Как пользователь, я хотел бы видеть различные доступные автомобили, чтобы я мог выбрать наиболее подходящий для меня вариант.

1. User selects items to rent
2. The User provides payment and shipping information
3. User orders the items
4. The system responds with confirmation of the order and a renting number that the user can use to check out the vehicle.
5. The system will also provide the user with a countdown for the remainder of the renting time.
6. The user may already have an account with the company with billing information.

1. User selects items to rent
2. The User provides payment and shipping information
3. User changes mind and chooses another vehicle
4. User deletes cart
5. User selects new items
6. User places order
7. The system respond with confirmation of the order and a renting number that the user can use to check out the vehicle.

1. The system will also provide the user with a countdown for the remainder of the renting time.
2. The user may already have an account with the company with billing information.

User story example