Как составить требования к проекту

Время на прочтение
13 мин

Количество просмотров 5.2K

Документ бизнес-требований (BRD) является отправной точкой для любого программного проекта или бизнес-решения. Благодаря такому документу члены команды приходят к единому мнению о том, что нужно создать, зачем это делать и как этого добиться.

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

Что такое документ бизнес-требований?

Документ бизнес-требований (Business Requirement Document. BRD) — это хорошо структурированное формальное описание предстоящего проекта. В нем объясняется, почему компании необходимо создать новое программное обеспечение или бизнес-решение. В BRD также описываются проблемы, которые будут решаться в рамках проекта, и то, какой доход они принесут (или сколько компания может потерять, если программное обеспечение не будет создано).

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

• Текущие проблемные моменты и цели проекта.

• Какие ресурсы необходимы компании.

• Этапы и промежуточные итоги проекта.

• Функциональные требования нового решения (технические и нетехнические).

• Ограничения проекта (все, что может замедлить или затруднить ход проекта).

• Стейкхолдеры.

• Риски.

• Предполагаемый коэффициент возврата инвестиций (return on investment, ROI).

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

Мы подробно разъясним, как следует оформлять BRD. Ниже представлен пример шаблона.

Перевод изображения:

Шаблон BRD

Краткое содержание

Дайте краткое и четкое резюме бизнес-требований данного проекта.

Цели проекта

Перечислите бизнес-цели проекта, следуя формату SMART (конкретные, измеримые, достижимые, реалистичные и ограниченные по времени).

• Увеличить MRR* на X% к концу года

• Снизить отток на X% к четвертому кварталу

• Повысить 1-недельное удержание пользователей на X% ко второму кварталу.

История проекта

Предоставьте некоторый контекст о проекте — какие вопросы или проблемы послужили его причиной?

Объем проекта

Опишите, что должно быть включено в проект, а что следует исключить.

Заинтересованные стороны

Перечислите внутренние и внешние стейкхолдеры, вовлеченные в проект.

• @Имя

• @Имя

• @Имя

Ограничения

Опишите все ограничения и лимиты, с которыми вам предстоит работать.

Время
Бюджет

Сценарии использования

Опишите сценарии, которые необходимо протестировать для достижения целей проекта.

Требования к продукту

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

ДОЛЖНЫ БЫТЬ
Требования, которые определяют успех проекта.

СЛЕДУЕТ ИМЕТЬ
Требования, которые добавляют ценность.

ЖЕЛАТЕЛЬНО ИМЕТЬ
Требования, которые добавляют удобство.

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

Указывают критерии и характеристики, которые будут влиять на систему.

Анализ затрат и выгод

Перечислите все затраты и экономию от проекта в виде бизнес-кейса.
*MRR ежемесячный доход компании с платящих клиентов

Почему важны документы бизнес-требований?

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

Фактически, Институт управления проектами (Project Management Institute. PMI) обнаружил, что без предварительного планирования команды проваливают проекты в два раза чаще, чем те, которые подготовились к работе. PMI также выявил, что планирование помогает командам достичь 77% своих целей по сравнению с 56% у тех, кто имеет низкий уровень развития проектного управления.

BRD также позволяют вашей команде:

• Контролировать общее состояние проекта.

• Объединить стейкхолдеров и членов команды для достижения консенсуса и сотрудничества.

• Снизить риск неожиданных изменений проекта.

• Понимать бюджет и ожидаемую окупаемость инвестиций.

• Понять ограничения проекта и найти оптимальное решение для их устранения.

• Способствовать повышению ответственности команды путем постановки четких, транспарентных целей.

Как составить документ бизнес-требований

Здесь вы узнаете, что нужно написать в каждом разделе документа бизнес-требований. Для того чтобы облегчить понимание процесса, мы объясним каждый шаг на примере.

Итак, для начала представьте, что ваша компания хочет создать систему управления контентом для специалистов TikTok. То, что у вас есть сейчас, — это путаница в Google Sheets и заметки на бумаге. Ваша цель — планировать, управлять и оценивать эффективность TikTok в одном месте.

Исходя из этого, давайте начнем излагать наши бизнес-требования.

Как написать документ о бизнес-требованиях

1. Начните с резюме.

2. Сообщите о бизнес-целях.

3. Объясните историю проекта и его необходимость.

4. Определите объем работ.

5. Определите требования к функциональности проекта.

6. Определите ключевых стейкхолдеров.

7. Сообщите об ограничениях проекта.

8. Составьте график работ.

9. Подведите итоги анализа затрат и прибыли.

1. Начните с резюме

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

• Текущие проблемные места и то, как они влияют на бизнес.

• Что вы предлагаете в качестве решения.

• Релевантные данные, например, ожидаемая рентабельность инвестиций.

• Крайний срок выполнения проекта.

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

Для нашего проекта TikTok CMS (Content Management System ― система управления контентом) резюме будет выглядеть следующим образом:

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

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

2. Сообщите бизнес-цели

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

Давайте определим цели для нашей TikTok CMS:

• Увеличьте окупаемость рекламных объявлений в TikTok на 10% в ноябре.

• Ускорьте создание постов, чтобы опубликовывать их по 2 штуки в день.

• Создайте аналитический отчет для доступа к показателям Tik Tok и их анализа в одном месте.

• Определите наиболее эффективные кампании TikTok, чтобы масштабировать их.

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

3. Объясните предпосылки проекта и его необходимость

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

Вот предыстория нашего примера с TikTok:

У нашей команды нет подробного отчета о ROI в TikTok. TikTok CMS поможет сократить расходы на кампании TikTok и увеличить ROI. Мы также определим наиболее эффективные кампании с точки зрения ROI.

4. Определите объем работ

Это самая важная часть вашего BRD. Данный раздел должен включать:

• Подробный обзор целей проекта.

• Основные этапы.

• Результаты проекта.

• Критерии приемки.

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

5. Определите требования к функциональности проекта

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

Для нашей CMS TikTok понадобятся:

• Отображение в календаре задач по управлению контентом.

• Возможности отчетности.

• Ежемесячная аналитика эффективности для каждого поста в отдельности и группы постов.

• Фильтрация по различным кампаниям.

6. Определение основных стейкхолдеров

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

Давайте рассмотрим наш пример.

• Директор по маркетингу: Утвердить создание TikTok CMS.

• Менеджеры проекта: Отвечают за декомпозицию проекта, назначение членов команды и обеспечивают выполнение проекта в соответствии с графиком.

• Руководитель команды (тимлид) TikTok: Отвечает за создание контента и сбор показателей производительности.

7. Сообщите об ограничениях проекта

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

Вот хороший пример проектных ограничений для технического продукта:

4.7 Ограничения

[Адресант.Компания] должна принять во внимание следующие ограничения при составлении схемы технических деталей [название проекта] :

4.7.1 В настоящее время (бизнес-система) не позволяет использовать (описание ограничений).

4.7.2 Пользователи (бизнес-системы) в настоящее время ограничены функциями, которые включают [ограничения описание] .

4.7.3 В настоящее время существует ограничение на хранение данных в размере (ограничение на хранение данных), которое ограничивает систему до (описание ограничений).

4.7.4 Отчетность и другие сведения о системе в настоящее время ограничены (описание ограничений) из-за (дополнительное описание ограничений).

4.7.5 Пользователи могут обрабатывать только до (описание ограничений) в рамках (бизнес-система).

8. Составьте график

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

Для нашего проекта TikTok CMS график выглядит следующим образом.

• Этап 1. Завершить X к декабрю 2022 года

• Этап 2. Разработка и обеспечение качества функционала X к марту 2023 г.

9. Подведите итоги анализа затрат и прибыли

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

Ваша цель — убедить руководителей в том, что новый проект стоит вложенных инвестиций. Подкрепите свои доводы фактами и цифрами.

5 замечательных примеров документов бизнес-требований

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

Шаблон BRD от PandaDoc

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

Цели бизнеса

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

2.1 Проектное решение

Новое (проектное решение) поможет [Клиент.Компания] достичь своей цели [бизнес-результат]. [Адресант. Компания] будет осуществлять контроль качества на каждом этапе процесса, чтобы избежать проблем при внедрении.

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

2.2 Значение

Благодаря [название проекта], [Клиент.Компания] может продвинуться дальше к достижению своей цели [цель клиента]. Тем самым [Клиент.Компания] создает себе условия для (общая бизнес-стратегия).

Шаблон TechWhirl BRD

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

Лучший вариант для: Объяснения сложных бизнес-процессов и зависимостей.

Перевод изображения:

TECHWhirl
Шаблон для технологического коммьюнити
BRD

5 Бизнес Требований

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

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

Требования в этом документе имеют следующие приоритеты:

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

Шаблон BRD в Asana

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

Перевод изображения:

Шаблон документа с бизнес-требованиями
Название проекта: Блог по техническому маркетингу
Руководитель проекта: Салли Браун
Дата отправки: 31 января 2022 г.
Статус документа: черновик, предложено V,  утверждено, проверено

1. Краткое изложение

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

2. Цели проекта

• Повысить удержание клиентов на 10% в годовом исчислении

• Увеличить количество просмотров веб-сайта на 1000 в месяц

• Увеличить коэффициент конверсии в среднем на 20%

3. Объем проекта

Маркетинговая команда напишет контент для блога и будет сотрудничать с командой

SEO и дизайнеров для его оптимизации. Мы будем распространять четыре подробных поста в месяц.

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

5. Основные стейкхолдеры

6. Ограничения проекта

7. Анализ затрат и выгод

Шаблон BRD в Smartsheet

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

Хотите увидеть больше макетов? Вот 10 бесплатных шаблонов BRD от Smartheet (все они составлены по одному образцу).

Перевод изображения:

ШАБЛОН ДОКУМЕНТА О БИЗНЕС-ТРЕБОВАНИЯХ

ДЕТАЛИ ПРОЕКТА
НАЗВАНИЕ ПРОЕКТА
СОЗДАТЕЛЬ
НОМЕР ДОКУМЕНТА
ДАТА
ВЕРСИЯ №

1. КРАТКОЕ РЕЗЮМЕ СНАПШОТ

Представьте здесь резюме (обзор ваших бизнес-требований). Ваше резюме должно представлять собой «моментальный снимок» (снапшот) цели ваших бизнес-требований, включая краткое описание любого анализа, выводы, детали проекта, объём, бизнес-факторы, предлагаемый процесс, текущий процесс и функциональные требования. Резюме

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

• Какова цель (назначение) этого документа бизнес-требований (BRD)?

• Кто является аудиторией этого документа бизнес-требований?

Шаблон BRD ClickUp

Ищете простой BRD для управления вашими проектами? Попробуйте этот шаблон от ClickUp. Здесь есть только основные разделы (с листами), которые вы можете легко заполнить онлайн. Команды по маркетингу и продажам могут использовать данный шаблон в процессе доработки CRM, разработки API-коннекторов и т.д.

Лучше всего подходит для: Небольших внутренних проектов с минимальным количеством требований и результатов.

Перевод изображения:

Документ бизнес-требований (…
Резюме
Цели проекта
Объем проекта
Бизнес-драйверы
Функциональные требования
Финансовые отчеты
Стейкхолдеры
Расписание и сроки
Анализ затрат и выгод

Расписание и сроки

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

Результаты
Крайний срок
Ответственное лицо

Составление документа о бизнес-требованиях

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

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

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

• Записаться на открытый урок

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

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

Здесь не будет базовой теории, что есть требование и что оно должно соответствовать SMART (надеюсь, вы это и так знаете). Скорее, я покажу некие best practice, как требования лучше оформлять в документации.

Начнем с обсуждения:

Если тема окажется интересной, то в следующей статье посмотрим на использование более продвинутых инструментов, таких как:

1. Пишите просто

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

Здесь, как и в дизайне интерфейсов, отлично работает правило: «Не заставляйте меня думать», про которое писал Стив Круг в одноименной книге.

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

Пример — Упрощаем составное требование

Исходное требование:

«Должна быть возможность удалить конкретный товар или сразу все товары из корзины».

По сути, данное требование содержит два отдельных требования:

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

2. Используйте форматирование

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

Используйте средства, которые доступны вам в любом редакторе:

Например, если вы используете союз «и» (или несколько таких союзов), то лучше каждое условие написать с новой строки.

Пример — Применяем форматирование

Исходное требование:

«Необходимо перевести заказ в статус «Доставляется», если заказ оплачен и весь товар есть в наличии на складе.»

Давайте упростим восприятие этого требования. Получим следующее:

«Необходимо перевести заказ в статус «Доставляется», если:

Что мы сделали? Мы сняли часть когнитивной нагрузки с того, кто будет изучать данное требование. Уже из форматирования становится видно, что:

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

3. Упрощайте требования

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

Пример — Оптимизируем длинное требование

Исходное требование:

«Заказ отображается в личном кабинете пользователя, если заказ находится в одном из статусов: «Новый», «Ожидает оплаты», «Оплачен», «Доставляется». Заказ в статусе «Доставлен» не должен отображаться в личном кабинете.»

Как можно его упростить:

«Заказ отображается в личном кабинете пользователя, если его статус не равен «Доставлен».

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

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

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

4. Используйте таблицы

Запомните, таблицы — ваш главный «бро» 🙂

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

Почему таблицы лучше работают:

Рассмотрим пример части из ТЗ на большую государственную систему из открытых источников:

«Успешно авторизованный пользователь, входящий в группу пользователей c ролью «Исполнитель», должен попадать на «UI-006 Главная страница личного кабинета», а пользователь, входящий в группу пользователей с ролью «Наблюдатель» – на «UI-092 Главная страница Мониторинга (дашборд)» подсистемы «Мониторинг». Если пользователь в личном кабинете настроил страницу по умолчанию, то открываемая страница должна определяться на основе выбранной настройки.»

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

«После успешной авторизации в системе, пользователю должна открываться стартовая страница, согласно условиям ниже:»

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

Таблицы для описания интерфейсов

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

Пример формы редактирования из того же ТЗ:

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

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

Когда использовать таблицы (спойлер — всегда!):

5. Используйте схемы

Схемы и диаграммы — это еще один отличный способ улучшить качество передачи знаний в команде разработки.

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

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

Контекстная диаграмма

Зачем нужна: Показывает как разрабатываемая система взаимодействует с внешними миром.

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

Когда использовать: На этапе проектирования системы, чтобы:

P.S. Еще эту диаграмму очень любят архитекторы.

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

Пример контекстной диаграммы из книги «Разработка требований к программному обеспечению» (Джой Битти, Карл Вигерс):

Схема бизнес-процессов (BPMN-диаграмма)

BPMN — это нотация описания бизнес-процессов в виде набора обозначений и ряда определенных правил.

Зачем нужна: Позволяет зафиксировать описание бизнес-процессов на этапе их дизайна и использовать это «знание» на этапе разработки и внедрения решения.

Когда использовать: Вообще, у BPMN довольно широкий спектр применения.

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

При разработке BPMN-диаграмм (в контексте описания требований) главное — избавиться от перфекционизма.

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

Качество ваших диаграмм будет зависеть от количества ранее созданных (волшебной пилюли, увы, здесь нет). На начальных этапах советую использовать базовые элементы:

Пример описания бизнес-процесса обработки инцидентов:

Если вам интересна отдельная статья про примеры построения BPMN-диаграмм на реальных примерах, напишите об этом в комментариях.

Диаграмма состояний

Зачем нужна: показывает как объект переходит из одного состояния в другое.

Когда использовать:

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

Пример диаграммы состояний для объекта «инцидент» из BPMN-диаграммы выше:

Заключение

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

Effective requirements gathering is the best way to control project costs, stay on schedule, and deliver a project you and your team are happy with.

It’s a relatively straightforward process — but it’s often overlooked, skipped, or poorly executed.

But gathering project requirements doesn’t have to be overly complicated. This guide will teach you different ways to collect project requirements, how to collect them, and when.

What is requirements gathering in project management?

Requirements gathering is the process of understanding what tasks need to be completed to deliver the project on time, within budget and scope, and to the client’s satisfaction.

It can be tricky, but when done correctly, it ensures everybody is on the same page about what should go into delivering the project successfully.

There are two main requirements:

1. Business requirements — “What is the goal?”
2. Technical requirements — “How do we accomplish it?”

For example, the business requirements of a marketing project may be to “increase leads by 20%.” The technical requirements will include completing tasks to deliver items such as social ads and lead magnets to target customers with special offers.

Purpose of gathering project requirements

35% of failed projects cite inaccurate requirements gathering as the primary cause of failure.

So gathering project requirements isn’t just necessary — it’s one of the most critical processes in the lifecycle of a project.

Gathering project requirements will help you to

• Understand the scope of work
• Identify and assess all project risks
• Accurately estimate the cost of the project
• Create a project timeline the client is happy with
• Effectively allocate and manage project resources 
• Not obliterate the project budget on irrelevant “requirements.” 

To stay organized as you grow and juggle projects, you need to build a process that collects, translates, and shares requirements from the client to the team so you can get it right time after time.

How to gather requirements for a project

It’s worth pointing out that all projects differ, so there is no “best” way to gather them. 

The guide below is a loose framework on which to base your processes. 

A six-step requirements gathering process

1. Decide when you will gather project requirements 
2. Assign roles to collect project requirements
3. Talk with project stakeholders
4. Review and analyze project requirements
5. Get approval from project stakeholders
6. Re-estimate the project costs
7. Build out your project plan
8. Monitor and track project progress

1. Decide when you will gather project requirements 

When you decide to gather project requirements will depend on how much information you managed to collect during your project intake process.

But the best case scenario would be to

• Sell your project with a variable price range
• Carry out a project discovery to fully understand project requirements
• Re-estimate and refine the project scope, cost, and timeline
• Sell each project phase of the project at a flat rate

If not, you can 

• Sell a discovery at a flat rate
• Sell the rest of the project based on your findings

Note: project discovery is the process of gathering requirements about a project to help people involved understand its vision, goals, and scope. Collecting project requirements is a part of this process.

2. Assign roles to collect project requirements

This will depend on your business and team size.

• Freelancer? That’s on you
• A small agency? Potentially the CEO
• Growing agency? A project lead or account manager

The best-case scenario? Get a project lead and a domain expert involved. 

But be aware that the domain expert/s will, and should, change depending on the type and complexity of the project.

Personalities and strengths play into this in a big way. For example, don’t hold them over the fire if your lead developer is terrified of direct client communication. Take the lead and have your developer create a list of questions you can ask the client, and be sure you fill all the gaps in the communication flow.

3. Interview project stakeholders

Once you’ve identified key client stakeholders, meet with them to get an idea of what they’re hoping to get out of the project. 

Understanding what the client wants to achieve is critical, as this will be the deciding factor behind what deliverables you create.

Your goal here is to understand fully

• What issue the client is facing?
• What’s the purpose and goal of the project?
• What does success looks like to them?
• What deliverables do they expect to receive?
• Who will need to be involved in the project?
• How much it will cost to deliver?
• How long it will take to deliver it?
• What risks and constraints may you encounter?

But the tricky thing is that clients don’t always know what they want, so they come to the pros (you) to figure it out.

Broad questions like “What are the requirements?” or something even deeper like “Are you looking for an X system with a Y interface via Z software?” will get you the same reaction.

So what do you do instead?

Ask the client questions about what they want and hope to accomplish. Then translate the desires, goals, and objectives into deliverables, a timeline, and a budget you and your team can work with.

Try asking questions such as

• “What problem are we trying to solve?” (and resist adding “and how do we solve it?”—that isn’t their job)

• “Can you describe [current solution] for me?”

• “What are the pain points/issues with the current process?”

• “What would an ideal experience for [project topic] look like?”

The goal is to ask the kinds of questions that describe the requirements regarding business needs — as they will provide more actionable info for your team.

Remember that you likely will only understand some of the project’s scope from the first interview. You may have to interview a few stakeholders to fully understand the project’s scope.

4. Gather and document your findings

This step is called requirements management. It’s about taking all the info from above and shaping it into something that makes sense for you and your team — and is achievable for your business.

You can streamline this step by using a project requirements template.

Depending on the project’s complexity, you might have to speak with multiple stakeholders to fully understand the project scope of work — as each may have different requirements.

But remember that not all project requirements are necessary for success.

Ask yourself — Is this requirement essential to achieve the business goal?

This is where you assess if the project requirements are:

• Inconsistent or duplicated
• Not feasible based on resources and logic

These two points are significant factors that can frustrate your team, waste their time, and cause delays.

Remember to identify and assess project risks as part of this process. Get your team together for a brainstorming session to figure out how to reduce those risks to ensure you stick to the project timeline and stay within budget.

5. Break down the deliverables into smaller chunks

Once you understand the project goals and objectives better, you can start to determine what effort needs to go into the project to deliver it successfully.

Use a Work Breakdown Structure (WBS) to break the project into manageable phases and tasks. 

What is a WBS?

It’s a hierarchical outline of the tasks required to complete a project. The WBS “breaks down” the structure of a project into manageable deliverables or phases.

It helps organize, visualize, and manage projects more efficiently. It serves as a framework for detailed cost estimation and control and an overall project schedule guide.

You can download our free WBS template below.

This will help you understand what resources are needed for the project, as well as help to create an initial project timeline and project budget.

6. Create your baseline budget and timeline

Once you fully understand the scope of work, you’ll need to create your baseline project budget and timeline.

You can do this by allocating costs to each task within your WBS.

Or, if you’re using Toggl Track, you can access past project data within the Project Dashboard to pull together a quick baseline estimate.

Task-level data can also be viewed within the same dashboard.

7. Get approval from project stakeholders

Meet with the client to present your baseline estimates. Get their feedback, ask more questions, clarify requirements, and get approval to start.

Don’t worry if this conversation leads back to step 3 and then back again to step 4 — yes, this might feel like a game of tennis where you’re the ball.

It’s all part of the process. Good project requirements gathering may mean a lot of back and forth with a client. 

But this remedies this expensive and infuriating process of reworking project deliverables long after the deadline because “that wasn’t quite what we wanted!”.

Important note: find out who has the final say in project requirements, so make sure you ask and find out.

8. Create your statement of work

Once you grasp everything well and the client is happy with your estimates,  it’s time to create and sign a statement of work.

This document should include all information you’ve collected in the previous steps.

Your SoW acts as your safety net if the project gets somewhat out of control. It should outline project tasks, deliverables, timelines, and costs for the client and anything out of scope.

The 5 Whys: How to uncover the info you need

The 5 Whys technique asks “why” until you get to the root of a problem — i.e., the need.

Commonly, it’s thought that five is the number of “whys” it takes to get to the core issue of a situation. It will help you and the client understand what the project needs to accomplish.

Here’s what the 5 Whys might look like during a project requirements gathering meeting. 

Although this example only takes four (it won’t always take five to get to the heart of the issue!).

Client: “We want a new website.”

Salesperson: “Why do you need a new website?”

Client: “The old one doesn’t work for us anymore.”

Salesperson: “Why does the old website not work?”

Client: “Our business has changed.”

Salesperson: “Why has your business changed?”

Client: “We’re handling more customers than we used to.”

Salesperson: “Why does the old website not support more customers?”

Client: “The old website lacks automation for key transactions, so our staff has to do everything manually.”

You’ve now reached an identifiable problem, which translates to a clear project requirement.

What happens is that people don’t always express the root of the problem while they’re talking. 

Often, the problem is so ingrained and obvious that we forget to say it out loud. 🤷

The 5 Whys help you identify the client’s core issue and create a tangible solution.

Other methods to establish project requirements

While the steps outlined above should help, they might be enough.

Most clients won’t fully understand what they want from a project initially. It may be a basic concept, an end deliverable, or a simple idea. 

But it’s your job to rework their idea and turn it into a viable solution you can deliver within their budget.

So what do you do if the client isn’t giving you much to work with?

Try the methods below and see how they fit into your process. You’ll find what methods work best for you in time, so start experimenting with your team and see how it goes.

• Send the client a questionnaire
• Use your expert judgment 
• Mind map with your team
• Use historical project data

1. Send the client a questionnaire

Questionnaires can be helpful if the client has a team of people working on the project with you. 

They provide three main benefits:

1. They give stakeholders time to process questions and leave detailed answers, ensuring nothing gets left out

1. They’re an efficient way to manage a project with many stakeholders

1. They save time during the interview or discovery session

But no. 3 might be the most crucial point. 

Getting thoughts, ideas, and problems out there ahead of the interview will save time, keep the conversation goal-oriented, and provide valuable context to your discussion.

2. Mind mapping with your team

Mind mapping is a visual type of brainstorming. A mind map is a diagram of notes to help your team generate ideas and classify information.

You place your main project objective in the center of the diagram. You then branch off into categories and details.

Creating a mind map is a simple process that can help your team layout ideas quickly but keep them organized.

Build your mind map with these steps:

1. Create a central idea
2. Build branches coming off of it to show core ideas derived from the central point
3. Create secondary and tertiary branches coming from the core ideas
4. Continue this, connecting any relevant ideas

This allows free, uninhibited expression where you can just put thoughts to paper (or screen).

Historical project data

Looking back at similar past projects is like having a tiny subject matter expert on your computer.

Digging through past projects to see what tasks they contained, their outcomes, and their milestones will give you solid insight into what a project like this needs to be successful.

This is what reviewing a past project looks like in Toggl Track:

Toggl Track’s online time reporting gives you clear visibility into past projects and their accomplishments. They allow you to review the deliverables, overall time, budget, and other details you tracked.

A time tracker is super helpful for accurately collecting requirements. Every project tracked is another piece of valuable data for your team.

When to gather project requirements

This will depend on your stage in your project intake process.

Is the client shopping for estimates? You may be better off giving them a ballpark estimate first.

Does the client have the budget and want more information from you? You should skim through this process to establish a high-level budget estimate.

Is the client ready to work with you? You should go through this process to gather all project information to create a more comprehensive estimate and timeline.

Check out our article ‘How to Estimate the Cost of a Project in 8 Steps’ to learn more about the different estimates you can create.

Gathering project requirements is a skill to hone

Collecting project requirements in project management is crucial to repeatable success. It keeps project scope in line, satisfies stakeholders, and lets you comfortably stay within budget and deadline.

It may feel a little daunting going into a discovery call when you know it’s your job to ask the right questions and gather the correct information for your team — but it’s a skill you can hone.

It won’t be long before you have a defined methodology and a repeatable process to use time and time again — which helps you and impresses the client. 😎

For the next steps, check out our blogs on project cost estimating and project time estimation.

Образец оформления титульного листа

Министерство
образования, науки и

молодежной
политики Нижегородской области

Государственное
автономное

профессиональное
образовательное учреждение

«Городецкий
Губернский колледж»

ИНДИВИДУАЛЬНЫЙ ПРОЕКТ

Тема: Металлы и их
соединения в моей профессии

г. Городец, 2021

Пример оформления
СОДЕРЖАНИЯ

Содержание

Введение …………………………………………………………………….3

1. Режим дня как
основа здорового образа жизни……………………………4

1.1
Здоровье как ценность человека………………………………………4

1.2
Составляющие здорового образа жизни………………………….…5

1.3
Понятие и значение режима дня в обеспечении здорового образа
жизни………………………………………………………………………………………………6

2. Режим дня для
людей различных возрастных категорий…………………..8

2.1
Режим дня детей и подростков ………………………………………8

2.2
Режим дня взрослого человека……………………………………….10

Заключение. …………………………………………………….……….….13

Список использованных источников…………………………….14

Приложение …………………………………………………………….……15

ВВЕДЕНИЕ

Введение
включает актуальность темы, цели и задачи.

Для
описания актуальности темы проекта могут быть использованы следующие
речевые обороты:

«Актуальность
темы нашей работы определяется тем, что в настоящее время…».

«Актуальность
данной темы обусловлена тем, что….».

«В
современном мире … имеет большое значение, так как…».

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

«Вопрос …
в последние годы оказывается в фокусе исследовательского внимания…». …

«Тема… является
предметом оживленных дискуссий…».

«Проблема…
привлекает к себе пристальное внимание ученых и общественности из-за того,
что…».

«В последнее время появилось … и люди
стали все чаще задумываться над тем …».

Формулирование
цели.

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

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

Например,
«Провести сравнительный анализ наиболее распространенных и используемых марок
жидких средств для мытья посуды: «Fairy», «Pril», «AOS», «SORTI»; «Приготовить
твердое и жидкое мыло в лабораторных и домашних условиях»; «Сделать приборы по
физике для демонстрации физических явлений по теме «Давление» своими руками»,
«Создать страноведческий справочник для подготовки к урокам английского языка».

Для
выражения задач, как и в случае постановки цели, лучше использовать глаголы:

—       изучить
литературу по теме и выяснить…

—       определить
категории …

—       ознакомиться
с методами …

—       создать
модель (методику) …

—       провести
серию опытов …

—       апробировать
модель (методику) …

—       разработать
рекомендации …

—       сформулировать
…

—       предложить
способы решения … и др.

Примеры формулировки задач

Задачи (информационный проект):

—      
изучить литературу,
статистические данные по теме проекта;

—       представить основные сведения о вреде
достижений цивилизации;

—       проанализировать результаты анкетирования и
интервьюирования.

Основные требования к
оформлению проекта

Текст документа выполняют с использованием
компьютера на одной стороне листа белой бумаги формата А4. Гарнитура шрифта
основного текста – «Times New Roman». Размер шрифта для основного текста – 14
пт, для таблиц – 12 пт или 14 пт. Междустрочный интервал основного текста –
полуторный, цвет шрифта – черный. Во
всей работе текст выравнивается по ширине рабочего поля листа. Текст следует размещать, соблюдая размеры
полей: левое – 30 мм, правое – 10 мм, верхнее – 20 мм, нижнее –20 мм. Абзацный
отступ – 1, 25. Размеры полей должны быть одинаковыми на всех листах работы.

Нумерация страниц

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

Титульный
лист включают в общую нумерацию страниц работы. Номер страницы на титульном
листе не проставляют.

Иллюстрации и таблицы, расположенные на отдельных листах, включают
в общую нумерацию страниц.

Приложения должны иметь общую с остальной
частью документа сквозную нумерацию страниц.

Требования к
мультимедийной презентации

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

Основные требования к
оформлению тезисов

Текст документа выполняют с использованием
компьютера на одной стороне листа белой бумаги формата А4. Гарнитура шрифта
основного текста – «Times New Roman». Размер шрифта для основного текста – 14
пт, для таблиц – 12 пт или 14 пт. Междустрочный интервал основного текста –
полуторный, цвет шрифта – черный. Во
всей работе текст выравнивается по ширине рабочего поля листа. Текст следует размещать, соблюдая размеры
полей: левое – 30 мм, правое – 10 мм, верхнее – 20 мм, нижнее –20 мм. Абзацный
отступ – 1, 25. Размеры полей должны быть одинаковыми на всех листах работы.

Образец оформления тезисов

Тезисы

Слайд 1

Здравствуйте,
уважаемая комиссия. Меня зовут Иванова Кристина, обучающаяся 14 группы
специальности «Мастер отделочных, строительных и декоративных работ». Хочу
представить вашему вниманию индивидуальный проект по химии на тему «Современные стройматериалы в
архитектуре городов».

Слайд 2

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

Цель
проекта: ознакомиться с современными стройматериалами.

В этой работе передо
мной стояли следующие задачи:

— исследовать как можно больше информационных ресурсов о
современных строительных материалах;

—
узнать об особенностях этих материалов (название и его значение);

— ознакомиться с современными материалами по средствам изучения
статей из интернета и новостей.

Слайд 3

Виды
строительных материалов

Известь
– один из древнейших связующих материалов.

«Негашеную
известь» получают обжи­гом различных природных карбонатов кальция.

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

и т.д.