​​User Story Map (USM) как механизм управления объемом и рисками проекта

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

Перейти к статье | BApedia

​​BI по-русски: что умеют BI-решения, доступные отечественному бизнесу

Статья о том, кто и зачем использует системы бизнес-аналитики, а также посмотреть на возможности ключевых игроков, представленных в России.

Перейти к статье | BIpedia

​​Алоха! Сегодня продолжаем разбирать вопросы, которые любят задавать на собеседовании на роль BA/SA и затронем тему Use cases:

#вопросыссобеседования | @ba_and_sa

Часть 13:

📍Вопрос 1: Что такое Use Case и какие критерии написания вы знаете?

✅Краткий ответ:
Use case - это текстовое представление взаимодействия между действующими сторонами (actors - пользователями, системами или внешними сущностями) и системой или программным приложением.

Другими словами Use case - это часть требований к ПО. Он помогает разработать качественный продукт, от которого пользователь получит ожидаемый результат.

Use case состоит из:

- Заголовок
- Участники
- Предусловие
- Шаги (описание сценария)
- Результат или гарантии успеха
- Альтернативные сценарии
- Постусловие

Критерии для написания use case:

Вот некоторые из них:

1. Ясность и простота: Use case должен быть написан четко и лаконично, избегая технической терминологии, чтобы его можно было легко понять как техническими, так и не-техническими заинтересованными сторонами.

2. Ориентированность на цель: Каждый use case должен четко определять основную цель или задачу, которую он должен выполнить. Он должен фокусироваться на конкретных действиях пользователя и ответах системы, связанных с этой целью.

3. Модульность: Use case должен быть модульным и независимым друг от друга. Он должен описывать отдельный, самодостаточный сценарий без перекрытий или общих шагов.

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

5. Интересы заинтересованных сторон: Учитывайте интересы и требования всех заинтересованных сторон, вовлеченных в проект, включая конечных пользователей, администраторов и техническую поддержку, при написании use case.

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

📎Материалы по теме:
- Use case. Инструкция по работе со сценариями использования для молодого аналитика
- Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case

📍Вопрос 2: Напишите пример Use Cases

✅ Краткий ответ:
Use Case: Регистрация пользователя

Описание:
Этот use case показывает, как новый пользователь может зарегистрировать аккаунт на интернет-магазине.

Основной actor: Новый пользователь

Предусловия:
- Пользователь открыл страницу регистрации.
- Пользователь находится на странице регистрации.

Шаги:
1. Пользователь открывает форму регистрации.
2. Пользователь вводит свое полное имя, адрес электронной почты и желаемый пароль.
3. Пользователь нажимает кнопку "Зарегистрироваться".
4. Система проверяет введенные данные.
5. Система проверяет, не зарегистрирован ли уже указанный адрес электронной почты.
6. Система отправляет пользователю письмо для подтверждения.
7. Пользователь получает письмо для подтверждения и переходит по указанной ссылке.
8. Система проверяет адрес электронной почты и подтверждает его.
9. Система выводит сообщение о подтверждении и автоматически выполняет вход пользователя в приложение.

Альтернативные сценарии:
- Если адрес электронной почты уже зарегистрирован, система выводит сообщение об ошибке и предлагает пользователю войти непосредственно или сбросить пароль.
- Если пользователь не получает письмо для подтверждения, он может запросить его повторно.

Постусловия:
- Пользователь зарегистрирован и авторизован на интернет-магазине.

📎Материалы по теме:
- Use case - что это + 3 примера
- Use case. Что это такое и зачем они нужны? С примерами

Источник: @ba_and_sa

‼️Предыдущие части смотрите по #собеседование #вопросыссобеседования

​​В анализе есть 3 пути: консалтинг, дата и ИТ

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

Перейти к статье | BApedia

​​Влияние нефункциональных требований на разработку программного обеспечения

Все требования к программным продуктом можно разделить на две группы. Это функциональные и нефункциональные требования (НФТ). Первые описывают «что» нужно сделать, вторые — «как» должна работать система.

Перейти к статье | BApedia

​​Диаграммы без боли и страданий: PlantUML

Системный аналитик всегда и везде сталкивается с бесконечным количеством диаграмм разного вида, с нотациями (правилами), чтобы нарисовать данные диаграммы и с бесконечным количеством инструментов для их описания. Но мало кто говорит о таком инструменте, как PlantUML.

Перейти к статье | BApedia

​​Метрики бизнес-аналитика на проекте

Статья о метриках, которые могут применяться для треккинга эффективности работы бизнес-аналитика на проекте.

Перейти к статье | BApedia

​​Онбординг пользователей, революция у аналитиков, веб-доступность: как сотрудники МТС Банка идеи до прода довели

В статье три истории от сотрудников МТС: они не постеснялись высказать свои идеи и запустили крутые проекты, которые уже принесли клиентам огромную пользу.

Перейти к статье | BApedia

​​Типичные ошибки при моделировании бизнес-процессов в нотации BPMN (Ч.1)

Если на собеседовании вас спрашивают "Имеете ли вы опыт моделирования бизнес-процессов", то в неявном виде вас спрашивают об опыте использования нотации BPMN. Мне могут возразить, что есть и другие нотации, например UML Activity diagram или старый-добрый IDEF0. Но на сегодняшний день место лидера за BPMN.

Перейти к статье | BApedia

​​Как на ранних стадиях проекта получить максимум информации от заказчика за минимум времени, USM как способ снизить риски

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

Перейти к статье | BApedia

​​Аналитика. Обзор, рекомендации, акценты применения

Сфера информационных технологий развивается крайне быстро. Мнения исследователей говорят о том, что она находится в состоянии "технологической "пред" сингулярности". Это оказывает определенное влияние, а на кого-то, может быть - даже давление. Содержать и развивать ИТ в целом - тренд, которому, по мнению многих руководителей необходимо следовать, и тогда он, как нить Ариадны, выведет в «светлое будущее».

Перейти к статье | BApedia

​​Понять и спросить: почему аналитику не надо сразу брать задачу

Помнит тут кто-нибудь телесериал «Понять. Простить»? В нём психологи разбирают проблемы в отношениях и пытаются помочь героям. Одна из телепсихологов в конце серии иллюстрировала разобранную историю с помощью кукол. В этой статье нашими куклами станут Аналитик и Заказчик. Вы узнаете, как аналитику следует общаться с заказчиком и почему без дополнительных вопросов брать задачу неэффективно.

Перейти к статье | BApedia

​​О критериях качества требований

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

Перейти к статье | BApedia

Тот самый сотрудник у которого на созвонах вечно какой-то посторонний шум в микрофоне

​​Как мы автоматизировали загрузку товаров на онлайн-витрину Fix Price

Автор расскажет сегодня о том, каким образом им удалось автоматизировать загрузку товаров на онлайн-витрину компании.

Перейти к статье | BApedia

​​От требований к постановкам задач на разработку с помощью архитектурного проекта

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

Перейти к статье | BApedia

​​Проектирование базы данных для самых маленьких — на примере кинотеатра

В данной статье автор покажет ход размышлений при проектировании базы данных.

Перейти к статье | BApedia

​​Pivot-Pivot-Pivot! Как управлять стремительно меняющимися требованиями

«Никто из нас не любит изменения. Но меньше всех любит их команда разработчиков, когда речь заходит о новых требованиях к задачам, уже взятым в спринт, а тем более, выполненным. В моем последнем проекте таких было достаточно, и эту статью я писала по результатам его ретроспективы. Поэтому в какой-то степени ее можно назвать работой над ошибками и даже мануалом для тех, кто будет менеджить требования в условиях “rapidly changing environment”.»

Перейти к статье | BApedia