Anton Sidorov homepage

Bookmark this to keep an eye on my project updates!

Follow me on GitHub

Аналитика

Виды аналитиков

Порядок артефактов\активностей

  • Бизнес-требования
    • определяют, какие преимущества должен получить заказчик при получении готового продукта
    • какие проблемы или задачи будут решены в результате его применения
    • формируется заказчиком ИС и основывается, прежде всего, на целях создания заказываемого продукта

CheckList:

  1. PP Предпроектная подготовка
    1. Бизнес цели (БЦ)
      1. Impact Mapping - какум проблему решаем: чтобы что?
  2. BT Бизнес-требования
    1. Сбор требований
      1. Customer Journey Map (CJM)
    2. Бизнес цели (БЦ)
      1. Metrics Driven Development, Lean Startup
    3. US
      1. User Stoty Map
      2. Event Storming
    4. БП
    5. UC
  3. FT Функциональные требования
    1. UI UX
    2. Модель данных
  4. Data Driven
    1. AB тесты
  • todo
  • https://habr.com/ru/articles/842280/

Сбор требований

Методы:

  • Опросник
  • Интервью
  • Записи заказчика
  • Изучение существующей документации
  • Повторное использование спецификации (ПЗ)
  • Представитель заказчика в компании разработчика (Agile)
  • Работа “в поле”
  • Обучение
  • Мозговой штурм (Agile)
  • Совещания (Agile)
  • Use Case

Виды артефактов

Цели

Понимание предметной области:

  • Какую проблему мы хотим решить? Impact Mapping
  • Кто пользователи/заказчики?
  • Как выглядит процесс от начала и до конца в реальном мире?
  • Какие риски и ограничения существуют?
  • Есть ли зависимости?
  • Какую ценность несет наше решение?

Карта влияния Impact Mapping

Зачем

  • Для формирования бэклога
  • Для определения рисков
  • Для выявления конфликтов интересов заинтересованных лиц
  • Для генерации гипотез по развитию продукта

Подход

Бизнес процесс (БП)

Бизнес-процесс — это набор действий людей и\или машин для достижения одной или больше целей. БП дают плохое представление о Движении информации. БП - это о том:

  1. кто какие Действия делает (User Task, Service Task)
  2. какова логика перехода от одного действия к другому
  3. какие события являются триггерами для этих действий

Виды нотаций моделирования бизнес-процессов:

  • BPMN (процессное моделирование)
  • IDEF (функциональное моделирование)

TO-DO

UC vs US

User Story (US) Пользовательские истории

  • Зачем
    • Сбор требований
    • Бэклог
    • Построение User Story Mapping
  • <Роль> [должен иметь возможность](https://scrumtrek.ru/blog/product-management/3364/user-story-instruktsiya-po-primeneniyu/) <возможность> в <показатель производительности=""> с <момент отсчета=""> в <условия эксплуатации="">, чтобы <ценность>
    • Например: Администратор клиники должен иметь возможность просмотреть данные о прошлых и запланированных посещениях пациента в течение 3 секунд после определения личности клиента по номеру телефона входящего звонка, чтобы добавить новое или изменить запланированное посещение.
  • <Система> должна <выполняемая функция=""> <объект> каждые <производительность> <единица измерения="">, чтобы <ценность>.
    • Например: CRM-система должна отправлять СМС-напоминание клиенту о предстоящем посещении за сутки перед посещением, чтобы он помнил о приеме и пришел вовремя.
  • Как определять Роль
  • INVEST - критерии хорошей US
    • I — Independent — Независимый
    • N — Negotiable — Обсуждаемый
    • V — Valuable — Ценный
    • E — Estimable — Оцениваемый
    • S — Small — Компактный
    • T — Testable — Тестируемый

User Stoty Map

Ряды данных USM

  • Первый ряд, или «позвоночник» (backbone) — шаги или этапы процесса
    • Расставляем по последовательности действий: то, что делается раньше — левее, более поздние шаги процесса — правее.
  • Второй ряд — пользователи или акторы
  • Третий ряд — требования или сценарии: user stories
    • Карточки расставляются по приоритету: чем выше приоритет, тем выше карточка.

Альтернатива Event Storming.

Use Case (UC) Сценарии использования

  • Описывает взаимодействие двух или большего количества участников (Акторов), имеющее конкретную цель
  • Описание решения цели пользователя в системе в виде Use Case должно определять
    • цель
    • акторы
    • пред- и пост-условия
    • триггеры
    • основные и альтернативные потоки
    • бизнес-правила
    • результат
  • объединяет функциональные требования по контексту для достижения цели пользователя, т.е. один UC может содержать более одного ФТ на множество ИС
    • можем выявить гораздо больше функциональных требований: практически каждая строчка Use Case является отдельным функциональным требованием. Мы видим, какие функции должны выполняться вместе, а следовательно, у нас есть возможность выставлять приоритеты реализации этих требований так, чтобы они были готовы в одно время.
  • Например:
    • Регистрация пассажира на рейс. Актор - пассажир. Цель - зарегистрироваться на рейс.
    • AI генераторы use case
  • Уровни описания
    • абстрактный - деловой UC, не затрагивает технологий, рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется деловыми актерами (людьми, или системами, внешними к бизнесу) для достижения своих целей.
    • системный - системный UC использования обычно описывается на уровне функций системы и определяет функцию или сервис, предоставляемые системой для пользователя.
  • Этапы написания UC
    • Сбор информации\требований
    • Общая картина в виде диаграммы
    • Текстовый use case по отдельным задачам
Шаг Участник Описание шага\действия Альтернативный сценарий Х
1 ИС\Актор Действие\Триггер Вариант Х

Модель данных

  • Таблица
    • Поля, Тип данных, Обязательность, Правила валидации, Источник данных, Пример
  • Модель состояний (FSM)
  • ERD

Книги