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

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

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

Прежде чем начинать проект, обязательно нужно знать, какой результат (продукт) вы хотите получить. И порой этот продукт необходимо описать самым тщательным образом. Иными словами, нужно знать, какие требования заказчик предъявляет к продукту. Полный набор этих требований называют каталогом требований, или спецификацией.
Крупные и сложные проекты обычно насчитывают тысячи требований. Бизнес-анализ как раз и позволяет выявлять проблемы и определять, что требуется для их преодоления. В крупных проектах, таких, как разработка программного обеспечения, сбор требований является одним из важнейших этапов жизненного цикла проекта, котоорыый может занять несколько недель/месяцев.
Для выявления требований проводится серия структурированных интервью с заказчиками, которые позволяют точно определить их пожелания к готовому продукту. Попытка напрямую узнать у заказчика, какие результаты ему нужны, может закончится крахом: заказчик станет выдвигать все новые и новые требования, так что вы просто будете не в силах их удовлетворить. Помните, любое требование влияет на продолжительность и стоимость проекта. Соответственно, получая подробный список требований, вам нужно знать, являются ли они:

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

Выжимка по процессу формирования требований

Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, User Requirements.
Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

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

Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

Пример различий между пользовательскими и функциональными требованиями:
Пользовательское: «Система должна выводить отчеты на печать»
Функциональное: «Система должна обеспечивать вывод отчетов на печать, обеспечивать возможность выбора и настройки локального или сетевого принтера, выбора ориентации бумаги».

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

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

Схема процесса разработки с уровнями требований

Формирование и анализ требований

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

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Классификация и описание требований на пути от бизнеса к технической реализации

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

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

1. Описание контекста и списка ключевых заинтересованных лиц
2. Описание целей создания системы и критериев достижения
3. Ключевые бизнес-требования к решению и их приоритеты
4. Существующие и возможные ограничения на решение

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

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

• Бизнес-назначение
• Бизнес-рамки
• Обзор бизнеса
• Заинтересованные лица
• Организационная среда
• Цели и результаты
• Бизнес-модель
• Информационная среда
• Бизнес-процессы
• Политики и правила
• Ограничения деятельности
• Организационная структура
• Концепция использования системы
• Сценарии эксплуатации
• Проектные ограничения

Пользователь — Требования пользователя

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик

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

Проблемы при формировании пользовательских требований

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

Системные требования

Системные требования описывают свойства и методы всех объектов системы. Программирование – это разработка и реализация структур данных и алгоритмов. Для разработки системы программисту необходимо знать структуры данных, необходимые для реализации системы, и алгоритмы (бизнес-правила/процедуры/пакеты обработки данных), которые ими манипулируют. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.
Системные требования — это более детализированное описание пользовательских требований.
Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.

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

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

Стандартные формы для специфицирования функциональных требований:

• Описание функции или объекта.
• Описание входных данных и их источники.
• Описание выходных данных с указанием пункта их назначения.
• Указание, что необходимо для выполнения функции.
• Если это спецификация функции, необходимо описание предварительных условий (предусловий), которые должны выполняться перед вызовом функции, и описание заключительного условия (постусловия), которое должно быть выполнено после завершения выполнения функции.
• Описание побочных эффектов (если они есть).

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

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

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

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

• легкость и простота использования;
• легкость перемещения;
• целостность;
• эффективность и устойчивость к сбоям;
• внешние взаимодействия между системой и внешним миром;
• ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.

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

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

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

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

Организационные требования

Организационные требования отображают политику и организационные процедуры заказчика и разработчика ПО. Включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

• Физическое размещение сервисов.
• Размещение адаптеров к информационным системам.
• Предоставление канала для взаимодействия информационных систем.
• Обеспечение независимости от адресов, протоколов и интерфейсов при взаимодействии систем.
• Трансформация данных при взаимодействии.
• Маршрутизация сообщений.
• Обеспечение инфраструктурной функциональности, включая мониторинг, логирование, безопасность, и т. д.

Интеграция точка-точка

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

Интеграция данных

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

Задачи интеграции данных:

• Передачи больших объемов данных, включающая логику преобразования данных.
• Синхронизация (репликация) данных информационных систем

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

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

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

Пользовательский интерфейс — часть программной системы. Требования к пользовательскому интерфейсу могут быть разбиты на две группы:

• требования к внешнему виду пользовательского интерфейса и формам взаимодействия с пользователем;
• требования по доступу к внутренней функциональности системы при помощи пользовательского интерфейса.

К первой группе можно отнести следующие типы требований:

• Требования к размещению элементов управления на экранных формах
• Требования к содержанию и оформлению выводимых сообщений
• Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

• Требования к реакции системы на ввод пользователя
• Требования к времени отклика на команды пользователя

Управление требованиями

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

Кто читает документацию

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

Как правильно сформулировать и контролировать цель проекта?

Как и у всех путешествий, у проекта улучшения процессов должна быть цель. Если не определить конкретных целей по улучшению, люди не смогут работать согласованней, а вы не сможете сказать, есть ли движение вперед, не сможете определять приоритеты задач и сказать, когда цель достигнута.
Метрика — измеримая характеристика проекта, продукта или процесса.
Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

Если вы выбрали реалистичные KPI для своих целей, но не видите признаков прогресса по истечении разумного времени, нужно провести расследование:

• Правильно ли были проанализированы проблемы и выявлены их первопричины?
• Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
• Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
• Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
• Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
• Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?

Документы процесса разработки и управления требованиями (по Вигерсу)

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

Документ по управлению требованиями

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

Количество просмотров 2.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 мая. На занятии ведущий системный аналитик поделится секретами успешного освоения профессии, расскажет о ключевых навыках, которые помогут реализоваться и стать востребованным специалистом. А также поможет понять, какие именно темы нужно изучить для успешного трудоустройства. Зарегистрироваться можно по ссылке ниже.

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

Продолжаем разговор о требованиях. Часть 1

Повторим, что такое требование:

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

Кратко: требование это зафиксированное желание пользователя, которое должна выполнять система.

Это определение неидеально. Потому что есть требования, которые пользователь явно не высказывает, например, работа системы в режиме 24/7, или пользователь высказал какое-нибудь пожелание, но оно не было реализовано. Особый случай: требование высказано в устной форме. На мой взгляд, если требование не зафиксировано в письменном виде, то оно не существует. 

Требования можно разделить на две большие группы: 

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

Функциональные требования — что система должна делать. 

К функциональным требованиям относят:

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

Что такое требование и дизайн по BABOK

Начнем с определений по BABOK®Guide: требование – это пригодное для практического использования представление решения в виде условия или возможности, которые необходимы заинтересованной стороне (стейкхолдеру) для достижения цели, инициированной потребностью. BABOK®Guide различает следующие виды требований:

• Бизнес-требование (business requirement), которое отвечает на вопросы «Почему это нужно?» или «Зачем я этого хочу?» и представляет собой отображение целей, задач и результатов, объясняющих, для чего было инициировано изменение и каким образом будет оцениваться успех его реализации. Подробнее о том, как выявить и сформулировать бизнес-требования с примерами читайте здесь.
• Требование стейкхолдера (stakeholder requirement), которое отвечает на вопрос «Что нужно?» и описывает потребности отдельной заинтересованной стороны или целой группы стейкхолдеров, необходимые для выполнения бизнес-требований. Фактически, они могут играть роль проводника от бизнес-требований до требований к решению.
• Требование к решению (solution requirement), которое отвечает на вопрос «Что я хочу?» и описывает возможность или качество решения, удовлетворяющие требованиям стейкхолдера. Требования к решению делятся на функциональные требования и нефункциональные. Функциональное требование (functional requirement) означает поведенческую возможность, которую должно предоставлять решение. Нефункциональное требование (non-functional requirement) описывает особенности эксплуатации: производительность, информационную безопасность, удобство использования и выражается в измеримых показателях, которые являются своего рода ограничениями варианта реализации (дизайна) решения. Подробнее про нефункциональные требования читайте в нашей новой статье.
• Переходное требование (transition requirement), которое отвечает на вопрос «Каковы условия реализации перехода от бизнес-потребности к внедренному решению?», описывая возможности решения и условия, каким оно должно соответствовать для перехода из текущего состояния в целевое. В отличие от других видов требования, переходное требование является временным, т.к. становится не нужным после завершения изменения. Например, требование относительно форматов и процедур преобразования данных при переходе от одной системы к другой.

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

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

При этом руководство BABOK отмечает, что в ИТ-сфере термин проект (дизайн) обычно используется именно для технических вариантов решения, которые создаются непосредственно специалистами по реализации: разработчиками программного обеспечения, ИТ-архитекторами и т.д. А требование означает выдвигаемые бизнесом условия или ожидаемые возможности.

Трассировка требований по BABOK®Guide

Задачи управления требованиями в BABOK®Guide

Из 6-ти областей знаний BABOK целых 2 посвящены непосредственной работе с требованиями: «Управление жизненным циклом требований» (Requirement Life Cycle Management) и «Анализ требований и определение дизайнов» (Requirements Analysis and Design Definition). Как видно из названия, область знаний «Анализ требований и определение дизайнов» носит инструментальный характер и сосредоточена на моделировании – именно здесь разрабатываются различные виды процессных и структурных диаграмм, например, UML, BPMN, IDEF0, EPC, DFD или ERD, чтобы описать поведение и строение проектируемого решения, а также процедуры работы с ним через решение следующих задач бизнес-анализа:

• Спецификация и моделирование требований (Specify and Model Requirements)
• Верификация требований (Verify Requirements)
• Валидация требований (Validate Requirements)
• Определение архитектуры требований (Define Requirements Architecture)
• Определение вариантов дизайна (Define Design Options)
• Анализ потенциальной ценности и рекомендация решения (Analyze Potential Value and Recommend Solution)

Чем отличается верификация от валидации, читайте в нашей новой статье. А непосредственное управление требованиями выполняется в рамках области знаний «Управление жизненным циклом требований» и включает следующие задачи работы с требованиями:

• Трассировка (Trace Requirements)
• Поддержание (Maintain Requirements)
• Приоритизация (Prioritize Requirements)
• Оценка изменений (Assess Requirements Changes)
• Утверждение (Approve Requirements)

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

Практическое управление требованиями реализуется с помощью соответствующих программных инструментов, например, Archi для моделирования диаграмм, и Jira для трассировки, приоритезации и поддержания требований. В следующей статье мы рассмотрим, как организовать управление требованиями в Agile-проектах с учетом особенностей гибких методологий и строгих предписаний ГОСТов на разработку ТЗ. А процессы и стадии жизненного цикла требований разбираются в этом материале.

А освоить техники и рекомендации BABOK®Guide по управлению требованиями и другим задачам бизнес-анализа вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации аналитиков, менеджеров и ИТ-специалистов в Москве:

• Управление бизнес-анализом – курс для руководителей
• Разработка ТЗ на информационную систему по ГОСТ и SRS

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

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

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

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

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

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

Руководство по проведению анализа бизнес-требований состоит из пяти этапов.

1. Определение ключевых заинтересованных сторон

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

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

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

2. Учет требований заинтересованных сторон

Узнайте требования всех ключевых заинтересованных сторон к новым продуктам или услугам. Каковы их ожидания и пожелания?

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

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

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

• Метод 1. Общение с заинтересованными сторонами

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

• Метод 2. Использование групповых семинаров или фокус-групп

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

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

• Метод 3. «Варианты использования»

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

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

• Метод 4. Создание прототипов

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

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

3. Классификация требований

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

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

4. Интерпретация и регистрация требований

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

Чтобы интерпретировать требования, выполните следующие действия:

• Точно определите требования. Убедитесь, что требования отвечают следующим условиям:
• Не подразумевают двусмысленности и не расплывчаты.
• Четко сформулированы.
• Достаточно подробны (перерасходы и проблемы проекта обычно возникают из-за появления неизвестных факторов, которые не были идентифицированы или достаточно хорошо проанализированы).
• Связаны с потребностями бизнеса.
• Точно определяют рабочую систему или дизайн продукта.
• Определите приоритеты требований. Хотя все требования важны, некоторые из них имеют приоритет над остальными, а бюджеты обычно ограничены. Поэтому определите, какие требования относятся к действительно важным, а какие к «дополнительным».
• Проанализируйте влияние изменений. Проведите импакт-анализ, чтобы убедиться в полном понимании последствий, которые ваш проект будет иметь для существующих процессов, продуктов и людей.
• Разрешите конфликты. Обсудите с ключевыми заинтересованными сторонами и разрешите любые конфликты требований. Для этого может пригодиться анализ сценариев, поскольку он позволит всем вовлеченным лицам понять, как предлагаемый проект будет работать в различных возможных «будущих ипостасях».
• Проанализируйте исполнимость. Определите, насколько надежным и доступным в использовании будет новый продукт или система. Детальный анализ может помочь выявить любые серьезные проблемы.

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

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

5. Получение официального подтверждения

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

From Wikipedia, the free encyclopedia

Business requirements, also known as stakeholder requirements specifications (StRS), describe the characteristics of a proposed system from the viewpoint of the system’s end user like a CONOPS. Products, systems, software, and processes are ways of how to deliver, satisfy, or meet business requirements. Consequently, business requirements are often discussed in the context of developing or procuring software or other systems.

Confusion arises for three main reasons.

1. A common practice is to refer to objectives, or expected benefits, as ‘business requirements.’ ^[1]
2. People commonly use the term ‘requirements’ to describe the features of the product, system, software expected to be created.
3. A widely held model claims that these two types of requirements differ only in their level of detail or abstraction — wherein ‘business requirements’ are high-level, frequently vague, and decompose into the detailed product, system, or software requirements.

Such confusion can be avoided by recognizing that business requirements are not objectives, but rather meet objectives (i.e., provide value) when satisfied. Business requirements whats do not decompose into product/system/software requirement hows. Rather, products and their requirements represent a response to business requirements — presumably, how to satisfy what. Business requirements exist within the business environment and must be discovered, whereas product requirements are human-defined (specified). Business requirements are not limited to high-level existence, but need to be driven down to detail. Regardless of their level of detail, however, business requirements are always business deliverable whats that provide value when satisfied; driving them down to detail never turns business requirements into product requirements.^[2]

In system or software development projects, business requirements usually require authority from stakeholders. This typically leads to the creation or updating of a product, system, or software. The product/system/software requirements usually consist of both functional requirements and non-functional requirements. Although typically defined in conjunction with the product/system/software functionality (features and usage), non-functional requirements often actually reflect a form of business requirements which are sometimes considered constraints. These could include necessary performance, security, or safety aspects that apply at a business level.

Business requirements are often listed in a Business Requirements Document or BRD. The emphasis in a BRD is on process or activity of accurately accessing planning and development of the requirements, rather than on how to achieve it; this is usually delegated to a Systems Requirements Specification or Document (SRS or SRD), or other variation such as a Functional Specification Document. Confusion can arise between a BRD and a SRD when the distinction between business requirements and system requirements is disregarded. Consequently, many BRDs actually describe requirements of a product, system, or software.

Overview[edit]

Business requirements in the context of software engineering or the software development life cycle, is the concept of eliciting and documenting business requirements of business users such as customers, employees, and vendors early in the development cycle of a system to guide the design of the future system. Business requirements are often captured by business analysts, who analyze business activities and processes, and often study «as-is» process to define a target «to-be» process.

Business requirements often include

• Business context, scope, and background, including reasons for change
• Key business stakeholders that have requirements
• Success factors for a future/target state
• Constraints imposed by the business or other systems
• Business process models and analysis, often using flowchart notations to depict either ‘as-is’ and ‘to-be’ business processes
• Conceptual data models and data dictionary references
• Glossaries of business terms and local jargon
• Data flow diagrams to illustrate how data flows through the information systems (different from flowcharts depicting algorithmic flow of business activities)

Business requirements topics[edit]

Benefits[edit]

Roles[edit]

Business requirements are typically defined by business analysts in collaboration with other project stakeholders.

Both parties may be responsible for determining the business requirements and developing technical solutions. Business analysts tend to be involved in developing the implementation approach, and managing the impact on all business areas, including stakeholder engagement and risk management.

Format[edit]

Traditional BRD Structure — [3]

Title Version Description of Change Author Date Contents Introduction Purpose Scope Background References Assumptions and constraints Document overview Methodology Functional requirements Context User requirements Data flow diagrams Logical data model / data dictionary Other requirements Interface requirements Data conversion requirements Hardware/Software Requirements Operational requirements Appendix A —

The most popular format for recording business requirements is the business requirements document (BRD). The intent behind the BRD is to define what results would be wanted from a system, however it might eventually be designed. Hence, BRD documents are complemented with a systems reference document (SRD) OR Technical Design Document (TDD) that details the design, technology performance and infrastructure expectations, including any technology requirements (non-functional) pertaining to quality of service, such as performance, maintainability, adaptability, reliability, availability, security, and scalability.

Completeness[edit]

Prototyping with early stage testing can assess the completeness and accuracy of captured business requirements. Stakeholders come in early to help define the requirements, and the result is sent to the project development teams who build the business system; other stakeholders test and evaluate the final deployed system. Clarity requires keeping track of the requirements and their solution, with a formal process for determining the appropriate template use. Business requirements scope is not necessarily limited to the stage of defining what needs to be built as a business system. It goes beyond, to envisage how a running business system is managed and maintained, and to ensure its maintained alignment with business goals or strategy. A business requirements document needs to be constantly revised in a controlled fashion. Having a standardized format, or templates that are designed for specific business functions and domains, can ensure completeness of business requirements, besides keeping the scope in focus.

Although commonly considered a means of evaluating requirements, prototyping actually usually shifts attention from business requirements to the product, system, or software being built. Prototypes are working software, which means they are three steps (product/system/software requirements, engineering/technical design of said product/system/software, and implementation of the design in program code) removed from business requirements. Prototypes are preliminary versions of the software the developer intends to implement. Because prototypes are fairly concrete, stakeholders who try out the prototype can give more meaningful feedback regarding some aspects of what the developer is creating, which is the developer’s interpretation of a way to satisfy business requirements, not the business requirements. Moreover, in order to create a prototype early and quickly, the Graphical User Interface (GUI) is emphasized and the «guts» are shortcut. The guts are the bulk of the program logic, and are where most business requirements would be addressed. In other words, issues that prototypes reveal are very unlikely to involve business requirements.

It is important to recognize the changes to requirements, document them, and keep the definition of requirements up-to-date. However, business requirements tend not to change nearly so much as the awareness of them. A business requirement may be present, but not recognized or understood by the stakeholders, analysts, and project team. Change is more apparent in regard to what is usually referred to as «requirements changes» — the product/system/software requirements. These tend to reflect the presumed ways of satisfying inadequately identified business requirements. Much of the difficulties attributed to achieving business requirements in fact reflect the common practice of devoting almost all «requirements» effort to what is actually high-level design of a product, system, or software. This stems from failing to first adequately define the business requirements the product/system/software must satisfy in order to provide value. Development practices commonly keep revising the product/system/software until they eventually «back into» a solution that seems to do what is needed, i.e., apparently addresses a business requirement. Such costly trial-and-error indirect ways of identifying business requirements are the basis for much of «iterative development,» including popular Agile development methods, that are touted as «best practices.»

Templates help prompt inquiry regarding particular topics that often may be relevant to business requirements. They can foster standardized documentation regarding business requirements, which can facilitate understanding. Templates do not ensure accuracy or completeness of business requirements. In fact, commonly misused, templates often negatively impact requirement research, since they tend to promote superficiality and mainly mechanical definition without meaningful analysis.

Difficulties[edit]

Business requirements are often prematurely hardened due to the large stakeholder base involved in defining the requirements, where there is a potential for conflict in interests. The process of managing and building consensus can be delicate and even political by nature. A lesser challenge, though common, is that of distributed teams with stakeholders in multiple geographical locations. It is natural that sales staff is closer to their customers, while production staff is closer to manufacturing units; finance and HR, including senior management are closer to the registered headquarters. A system for example that involves sales and production users may see conflict of purpose – one side may be interested in offering maximum features, while the other may focus on lowest cost of production. These sorts of situations often end in a consensus with maximum features for a reasonable, profitable cost of production and distribution.

To address these challenges, early stage stakeholder buy-in is achieved through demonstration of prototypes and joint working. Stakeholder workshops are common, either as facilitated sessions or simple huddled discussions, to aid in achieving consensus, especially for sensitive business requirements and where there is potential conflict of interest. Complexity of a business process is a factor. This may entail specialized knowledge required to comprehend legal or regulatory requirements, internal company-wide guidelines such as branding or corporate commitments to social responsibility. Business requirements analysis is not just about capturing the «what» of a business process along with «how» to provide its context. Translation into designing and building a working system may need to be addressed. At this stage, business requirements have to acknowledge technical details and feasibility.

A custom-built solution in not always required for every new set of business requirements. There are often standardized processes and products, which with some tweaking or customization, can serve to address the business requirements. The target business system is frequently constrained by a specific technology choice, budget, or available products already deployed.

Finally, standardization of format may cause difficulties. Multiple projects with multiple formats that lead to variation in structure and content of a requirements document renders these ineffective from a traceability and manageability perspective. In fact, when creating a template for use in a cross-functional requirement gathering exercise, different roles with complementary knowledge may find it difficult to work within a common format. It is therefore crucial to allow non-specialist or non-expert stakeholders to provide additional requirements by Appendices and additional attachments to cover their area of specification. Addressing various nuances, and arriving at a best fit, remains the single biggest challenge to effective requirements.

Identifying business needs[edit]

Includes the following steps:

1. Business definition
2. Understand business domain(s)
3. Organization goals
4. Core competence

See also[edit]

• Systems Development Life Cycle
• Systems engineering
• Software development process
• Business analyst
• Software Requirements Specification
• Requirements analysis
• Requirement
• Prototyping
• Software prototyping
• Business analysis

Bibliography[edit]

• Beal, Adriana. Requirement is what we have to do to achieve an objective www.bealprojects.com, 2012
• Goldsmith, Robin F. Discovering Real Business Requirements for Software Project Success. Artech House, 2004.
• Robertson, Suzanne and James C. Robertson. Mastering the Requirements Process. 2nd Edition, Addison-Wesley, 2006.

References[edit]