Привет! На связи лид команды аналитиков Magnus Tech Владислава Никитина.

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

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

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

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

Появление шаблона и почему это удобно

Если в компании нет своего стандартизированного подхода, аналитики составляют бизнес‑функциональные требования к системе с нуля. С опытом приходит понимание, что для этого стоит использовать готовый, заранее разработанный и структурированный шаблон (скачать из Google Docs).

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

«Рыбу» этого шаблона я составила на основе собственного опыта (более 10 лет аналитики в сфере IT): что‑то взяла из функциональных спецификаций, которые остались от работы с коммерческими заказчиками, что‑то из К.Вигерса. На протяжении нескольких проектов мы с коллегами обкатывали и дополняли шаблон, а затем стали применять его на новых проектах уже практически без изменений.

Структура шаблона

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

Шаблон состоит из трех блоков, которые заполняются по мере поступления информации:

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

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

Разделы шаблона достаточно универсальны, так что при необходимости их можно дополнить или сократить. Например, если мы не интегрируемся с другими системами, то убираем блок про интеграцию. Если основная задача проекта — доработка уже развернутого решения — сокращаем раздел с бизнес‑требованиям и уделяем основное внимание функциональным.

Бизнес-требования

В бизнес‑требованиях мы фиксируем целевой процесс в виде схемы. Обычно у наших заказчиков так или иначе уже выстроены бизнес‑процессы — с учетом автоматизации или без ее учета (если все ручное, «на бумаге»).

Сначала мы составляем схему этих процессов As Is (как есть). Затем оптимизируем процессы, учитываем, что можно автоматизировать, составляем схему To Be (как должно быть) и описываем ее в требованиях. Приведу пример на одном из процессов управления новостью, BPMN‑схема которого представлена ниже:

Затем каждый будущий процесс, зафиксированный на BPMN‑схемах, детализируем в отдельной таблице. Фиксируем операции процесса, прописывая кто и какие операции выполняет.

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

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

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

Функциональные требования

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

Начинаем с общих требований к интерфейсу, они отражают функциональность, которая должна присутствовать на каждом экране будущей IT‑системы.

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

Например, менеджер с доступом к информации об одном отделе компании или руководитель, которому будут доступны результаты работы всех менеджеров.

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

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

Мы детально перечисляем, какие данные содержит раздел, а также добавляем в шаблон функциональных требований макеты интерфейса. Здесь же фиксируются: атрибутивный состав объектов, сведения о сортировке и фильтрах, статусная модель сущностей. Прописываются все необходимые типы уведомлений и их источники.

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

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

Пользовательские истории на первый взгляд напоминают сценарии, но формулируются иначе и несут другую смысловую нагрузку.

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

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

Нефункциональные требования

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

Сюда же включаются общие требования к обмену данными между системами: какой инструмент будет использоваться, как часто будут отправляться данные и так далее. В то же время технические подробности об API и форматах данных при необходимости выносятся в отдельную спецификацию на интеграцию.

Корректировка и учет новых требований

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

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

Выводы и рекомендации, если вы хотите так же

Если хотите самостоятельно составить шаблон для описания бизнес‑функциональных требований к системе, то обращайте внимание на то, есть ли потребность в том или ином разделе. Может быть, уже какие‑то моменты определены? Например, если есть платформа, то есть и определенные требования к тому, куда и по каким правилам встраивать новую функциональность, с какими дополнениями.

Необходимый минимум, который обязательно должен входить в шаблон, это разделы функциональных и нефункциональных требований. Также в него стоит включить бизнес‑требования, потому что они в сжатом виде отражают то, как этой функциональностью будут пользоваться. Однако вам не обязательно начинать с нуля. Будем рады, если наш опыт пригодится другим аналитикам — изучайте и скачивайте наш шаблон из Google Docs.

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

Так, например, со временем может потребоваться расширить шаблон в части более детальных нефункциональных требований и фиксации дополнительных требований. Вероятно, есть и другие метрики, которые нужно будет зафиксировать. Например, временные показатели (заказ должен формироваться не более 5 секунд) или еще какие‑то вещи, которые важны именно для функциональности и бизнес‑велью. Может быть, стоит добавить критерии приемки работ и критерии успешности проекта.

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