Comments 22
Bizagi не пробовали использовать? По моему для вас будет самое то. Я именно про проектирование, а не про использование как BPMS.
Статья хорошая, спасибо за ваши примеры, особенно за разные надстройки для confluence. Правда хотелось бы отметить пару моментов:
очень странно, когда используется слово "функционал" не по своему прямому определению;
зачем НФТ включать в раздел БТ? Раз уж мы за структуру, отдельный раздел сделать не должно быть проблемой. Ну и вообще есть путаница с терминами. ФТ всегда пишутся без деталей реализации, а в статье всё намешано;
вот это формулировка порадовала. BPMN-нотация стала подмножеством UML.
Конечно, приветствуется и поощряется, если аналитик решил добавить схему, отрисованную в BPMN или какую-нибудь другую UML-диаграмму
ещё хотел придраться, что sequence не совсем архитектурная диграмма, но здесь всё чётко;)
И не увидел раздела с описанием методов. Вы его где-то отдельно ведёте или этим занимается другая команда?
Спасибо за ваш комментарий и замечания.
- С BPMN вероятно неудачная формулировка получилась. Отлично, что подметили.
- В статье мы рассказывали про требования для фронта, методы мы тоже проектируем, но для них есть отдельный шаблон. Возможно, это тема для еще одной статьи. Если кратко, то шаблон метода состоит из:
- названия метода
- алгоритма
- описания параметров на вход
- описания параметров на выход
- примеров запроса и ответа
- описание ошибок
Девчонки крутые!
Очень хорошо у вас получилось. Единственный момент, который смущает - у вас архитектуру задаёт аналитик? Какой у аналитика интерес в том, как это будет реализовано архитектурно? Архитектор, всё-таки, должен быть один, а не толпа, превращающая общую структуру в лоскутные взаимодействия.
Спасибо! Продумывать архитектуру у нас действительно задача аналитика, в сложных моментах привлекаем enterprise архитектора. В статье мы рассказывали про ФТ на фронт, но это не все, чем мы занимаемся, постановки на бэк мы тоже пишем. И в этой картине мира логично, что мы дружим между собой все написанное.
А не превращается все это в хаос благодаря наличия у всех понимания целевой архитекутры и надзору архитектора.
Отличная статья. Вот только повторить Ваш опыт смогут только те, кто успел купить нужные макросы Confluence. Остальным придется изобрести свой способ шаблонизации, к сожалению
Спасибо за комментарий!
Да, действительно, точь-в-точь повторить можно с купленными макросами.
Но для тех у кого их нет, но кто хочет использовать наш шаблон, есть два пути.
Первsй путь: попытаться их купить. Если компания большая, то как правило этот процесс реально устроить.
Второй путь: подойти творчески и сконцентрироваться на сути, а не на инструментах. Например, наши вкладки можно просто заменить на заголовки, а схемы вставлять скринами со ссылками на оригинальный файл.
Спасибо за статью, очень интересно и стуктурировано! Возникло пару вопросов, хотел уточнить. Во-первых, правильно ли я понимаю что вы как СА готовите данный артефакт и он используется как постановка для разработчика? Или этот документ сначала идет на согласование с заказчиком? Во-вторых, есть ли у вас в командах БА? Как фиксируете бизнес-требования? В каком виде вообще к вам (СА) поступает задача?
По моему опыту, БА описывают как раз варианты использования - то, что у вас в пункте "сценарии". А далее на основании согласованного UC ведется разработка. Было бы интересно узнать, как у вас выглядит процесс.
Добрый день.
Да, скоуп артефактов используется разработчиками и тестеровщиками. Перед тем, как отправить документ разработчикам, он проходит ревью. Как правило ревью делают другие аналитики, в т.ч руководитель со стороны аналитиков. Сами артефакты пишутся в тесной работе с PO команды, чтобы полноценно перенести все бизнес требования в более детальные требования для разработчиков.
Задача, как правило, приходит от PO команды, он же является источником бизнес требований. Если БТ зафиксированы в документе, то СА просто включает этот текст в набор своих артефактов(и доуточняет то, что упущено в БТ), если не зафиксированы, то СА интервьюирует PO и фиксирует БТ, как правило, в свободной форме.
По поводу БА.. У нас в продуктовых командах, чаще всего таковых нет, есть только PO и СА, которые делят функционал БА между собой.
Спасибо за статью!
Хочу немного "почелленджить"/подискутировать насчет обязательности sequence diagram в вашем шаблоне требований к фронту, в частности.
В примерах, диаграмма последовательности - это просто визуализация сценариев использования. Плюс-минус: в диаграмме есть HTTP коды ответов и название сущности, в сценариях есть входные параметры.
В визуализации нет ничего плохого. Тут вопрос рационального использования ресурсов аналитика: время на описание текстового сценария и на диаграмму (PlantUML - наше все) и дублирование информации. В случае изменения требований (банально поменяли API endpoint, например) нужно уже менять в 2-х местах: выходит дороже и есть риск "я забыл, а разработчик не туда посмотрел вот и баг".
Этот подход работает, когда сценарий использования описывает взаимодействие с черным ящиком, а диаграмма последовательности описывает что происходит внутри ящика: цепочку запросов между сервисами или вызовы контроллеров внутри определенного сервиса (на этот уровень детализации аналитикам лучше не соваться, имхо). Но это уже больше про end-to-end сценарий. Конкретно для фронта все сводится к коммуникации запрос/ответ с бэкендом. А у вас это уже описано в сценарии использования + есть описание нужных API endpoint.
Диаграммы - это хорошо. Но утверждение "диаграмма последовательности должна быть обязательно" все-таки спорное и, в данном случае, кажется излишним.
Спасибо за комментарий, расскажу подробнее про нашу документацию.
В сивквенсах мы описываем все взаимодействующие системы настолько схематично, насколько возможно. Очень полезно для второй линии и для развития продукта (надо понимать, где должны быть изменения). Решили хранить именно во фронтовом ФТ, так как разматывать сценарий от пользователя, который хочет что-то сделать, до мастер-системы проще, чем наооброот.
В сценариях действительно только запрос/ответ. Сценарий сделан чисто для фонта.
Правило про обязательность сиквенса появилось на заре попытки стандартизировать ФТ. Тогда мы пришли к выводу, что в документации должно быть упоминание всех используемых систем и последовательности обращения к ним.
Отличная статья, благодарю! Возник вопрос: в какой момент вы начинаете описание во вкладке "Дизайн"? Описание делается уже по готовым макетам или вы как аналитики рисуете прототип, описываете UI и после передаёте дизайнерам?
Добрый день!
У нас этот момент разнится от команды к команде.
В идеальной ситуации PO ставит задачу на дизайнера по созданию макетов. После того как макеты готовы, аналитик описывает их в документации в разделе "Дизайн". Но бывают команды, которые делают внутренние продукты, они дизайнеров не привлекают, а аналитик как раз рисует прототип для разработчика. Этот прототип помещают в раздел "Дизайн". Так я работала в своей первой команде. Использовала Drawio, он у нас идет встроенным макросом в confluence.
Также в создании дизайна принимает участие UX дизайнер, в случае, если он есть у команды.
Всё же вынужден подметить некоторые нестыковки:
В заглавии и во введении статьи вы пишете, что разработали шаблон функциональных требований, но при этом в структуру добавили раздел с бизнес-требованиями. Стоило бы определиться с назначением документа.
Диаграмма последовательности это не архитектура, а лишь способ отобразить взаимодействие пользователя и системы (в вашем случае фактически дополнение к сценариям использования).
Точки входа на мой взгляд относятся к дизайну (т.к. в вашем случае это именно представление навигации в интерфейсе пользователя), поэтому логичнее было бы указывать их в соответствующем разделе.
Как мы создали шаблон функциональных требований к разработке ПО