что такое бизнес требования проекта
Что такое бизнес требования проекта
Давайте поговорим о том, откуда берутся требования. И бизнес-требования (БТ), и нефункциональные требования напрямую вытекают из потребностей бизнеса.
Напомним, что нефункциональные требования (НФТ) определяют свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.
Из бизнес-требований, помимо функциональных (ФТ) и нефункциональных требований, напрямую могут вытекать ещё и требования причастных сторон. В свою очередь, из требований причастных сторон могут вытекать ФТ и НФТ.
Культурные образцы — это те требования, которые можно получить на основе стороннего опыта. То есть, изучая какой-то аналогичный готовый продукт на рынке, мы можем сформировать требования к своему продукту (даже если эти требования никто из стейкхолдеров не озвучивал напрямую).
Все виды требований возникают в конкретном контексте, то есть следуют из Операционного контекста, к которому относятся активы, спрос, технологии и так далее. Подробнее про влияние контекста на бизнес-требования смотрите в статье Бизнес-требования. Назначение.
В наглядном виде модель выявления требований представлена на схеме:
Модель выявления требований
Бизнес-требования играют важную роль на проекте, поскольку помогают определить смысл проекта и обосновать его необходимость. Именно бизнес-требования, как правило, используются для определения рамок проекта, то есть входят в состав концепции проекта.
Ввиду своей понятности всем заинтересованным лицам, бизнес-требования служат артефактом, на основе которого удобно заключать договоренности. Чем ниже уровень требований, тем больше нюансов, а значит, сложнее договариваться.
Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.
Также бизнес-требования часто используются на проекте для приоритизации решений: если есть понимание, как то или иное решение связано с БТ, приоритизировать его не составит труда. Именно БТ являются снованием для принятия решений в ходе проектирования и внесения изменений в реализацию проекта.
Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.
Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.
Исходя из определения Six Sigma, классификация требований будет опираться на критичные активности, т. е. бизнес-требования могут быть связаны с:
Вид БТ: Значимые характеристики продуктов или услуг
Вид БТ: Сбор, обработка, хранение и предоставление информации
На данный момент в профессиональных сообществах аналитиков ведутся активные дискуссии по поводу требований, сформулированных в негативной форме. Считается, что абсолютное большинство этих требований можно и нужно переформулировать в позитивную форму — это снизит риск непонимания.
Требование, заданное с позиции «Система должна делать…», задает конкретное направление действиям разработчика, а также дает некоторые ограничения — в отличие от формулировки требований с позиции «Система не должна…»
Но, конечно, существуют ситуации, когда необходимо сформулировать требования именно в негативной форме и, чаще всего, это касается решения задач безопасности.
Путаница возникает по трем основным причинам.
Бизнес-требования часто перечислены в документе с бизнес-требованиями или BRD. Акцент в BRD делается на процессе или деятельности точного доступа к планированию и разработке требований, а не на том, как этого достичь; это обычно передается в спецификацию или документ системных требований (SRS или SRD) или другой вариант, такой как документ функциональной спецификации. Путаница между BRD и SRD может возникнуть, если не учитывать различие между бизнес-требованиями и системными требованиями. Следовательно, многие BRD фактически описывают требования к продукту, системе или программному обеспечению.
СОДЕРЖАНИЕ
Обзор
Бизнес-требования часто включают
Темы бизнес-требований
Преимущества
Описание
| Уменьшите количество сбоев проекта | Структурированное объяснение бизнес-процесса или метода, определенного на ранней стадии жизненного цикла, помогает уменьшить количество сбоев проекта, которые возникают из-за неверно согласованных или неверно представленных требований, что приводит к несостоятельности ожиданий пользователей. |
| Подключается к более широким бизнес-целям | Четко определенные бизнес-требования помогают составить устав проекта, который является важным шагом в реализации бизнес-стратегии или бизнес-целей, и перейти к следующему логическому шагу по превращению его в ИТ-систему. Это помогает контролировать общее состояние проекта и обеспечивает положительное взаимодействие с ключевыми заинтересованными сторонами проекта, включая спонсоров. |
| Создание консенсуса и сотрудничество | Преимущество структурированного формата, типичного для документации бизнес-требований, помогает достичь положительного консенсуса и улучшить сотрудничество, когда группа заинтересованных сторон бизнеса может быть большой кросс-функциональной командой, распределенной географически. |
| Экономит затраты | Хорошее качество бизнес-требований при своевременном учете не только улучшает успех проекта, но и снижает общие затраты, связанные с запросами на изменение и соответствующими инвестициями в обучение, инфраструктуру и т. Д. |
Обе стороны могут нести ответственность за определение бизнес-требований и разработку технических решений. Бизнес-аналитики, как правило, участвуют в разработке подхода к внедрению и управлению влиянием на все области бизнеса, включая взаимодействие с заинтересованными сторонами и управление рисками.
Формат
Полнота
Шаблоны помогают запрашивать запросы по конкретным темам, которые часто могут иметь отношение к бизнес-требованиям. Они могут способствовать созданию стандартизированной документации, касающейся бизнес-требований, которая может облегчить понимание. Шаблоны не обеспечивают точность или полноту бизнес-требований. На самом деле, шаблоны, которые часто используются неправильно, часто негативно влияют на исследование требований, поскольку они, как правило, способствуют поверхностности и, в основном, механическому определению без значимого анализа.
Трудности
Индивидуальное решение не всегда требуется для каждого нового набора бизнес-требований. Часто существуют стандартизированные процессы и продукты, которые после некоторой настройки или настройки могут служить для удовлетворения бизнес-требований. Целевая бизнес-система часто ограничена выбором конкретной технологии, бюджетом или уже развернутыми доступными продуктами.
Наконец, стандартизация формата может вызвать трудности. Множественные проекты с множеством форматов, которые приводят к различиям в структуре и содержании документа требований, делают их неэффективными с точки зрения отслеживаемости и управляемости. Фактически, при создании шаблона для использования в упражнении по сбору межфункциональных требований разным ролям с дополнительными знаниями может быть сложно работать в рамках общего формата. Поэтому крайне важно позволить заинтересованным сторонам, не являющимся специалистами или не являющимися экспертами, предоставлять дополнительные требования в Приложениях и дополнительных приложениях для охвата области их спецификаций. Учет различных нюансов и достижение наилучшего соответствия остается самой большой проблемой для эффективных требований.
Определение потребностей бизнеса
Включает в себя следующие шаги:
Шаблон документа с бизнес-требованиями.doc
Наименование департамента
[НАИМЕНОВАНИЕ ПРИЛОЖЕНИЯ ИЛИ СИСТЕМЫ]
| Документ с бизнес-требованиями |
Документ с бизнес-требованиями
Руководство по использованию шаблона требований
Для того, чтобы правильно создать документ с описанием бизнес-требований, пожалуйста, придерживайтесь следующих принципов данного руководства. После завершения написания документа, удалите данный раздел.
| Назначение | Требование — это задокументированное условие или возможность продукта, сервиса или системы, которые должны соответствовать задачам проекта. Управление требованиями представляет собой семантический подход к выявлению, организации и документированию требований продукта, сервиса или системы. Документ с описанием бизнес-требований служит базовой линией проекта, которая поясняет, в бизнес-терминах, что необходимо сделать на этапе проектирования в проекте. Так как требования являются динамичными, то документ с бизнес-требованиями является постепенно изменяющимся документом, целью которого является записывать то, что известно на данный момент, а затем используя эти записи строить документ дальше по ходу развития проекта. Именно из этого документа появляется более конкретная проектная документация, которая формируется на основе потребностей проекта и других взаимодополняющих методологий. | ||||||||||||||||||||||||
| Владение документом | Бизнес-анализ и руководители проекта работают с бизнес-спонсором и любыми другими необходимыми бизнес или техническими лидер ами на проекте в рамках формирования документа с бизнес-требованиями. | ||||||||||||||||||||||||
| Когда документ формируется | Формирование документ с описанием бизнес-требований запускается во время начальной стадии выполнения проекта, который предшествует стадии проектирования в жизненном цикле управления проектами. Определение бизнес-требований является обязательным этапом во всех проектах. | ||||||||||||||||||||||||
| Template Completion Note: Text within brackets need to be replaced with project-specific information. | Сбор требований непростой процесс, как это может показаться изначально. Это достаточно сложная задача, поскольку требования: · не всегда очевидны; · могут поступать из многочисленных и разнообразных источников; · нуждаются в управлении кросс-функциональными группами людей; · могут вызывать сложности при формулировании в ходе написании документации; · могут формулироваться на разных уровнях детализации. Для проекта, который представляет собой усовершенствование существующего продукта, сервиса или системы, команда проекта проводит обзор существующих документов; поэтому документ с бизнес-требованиями, как правило, является более кратким. Тем не менее, проект, в ходе которого должен быть разработан новый продукт, услуга или система, как правило, будет содержать более детальный документ. 1. Не включайте раздел руководства к шаблону в итоговый документ. Введите информацию о проекте в заголовке страницы, нижние колонтитулы, титульный лист, участников по разработке документа, а также заполните информацию по контролю версий. 3. Для небольших проектов можно объединить все разделы требований в одну таблицу, добавив столбец «Тип требования». 4. Если некоторые требования не применяются в вашем проекте, то не удаляйте его, а пометьте его как «Не применяется» и укажите краткое пояснение, почему в текущем проекте данное требование не актуально. 5. Если на проекте имеются дополнительные требования, то ими нужно дополнить раздел 5. Можно создать отдельную таблицу для помощи в выявлении, определении и отслеживании требований. Обратите внимание, что если новое требование идентифицируется после того, как утвержден документ с бизнес-требованиями, то новое требование необходимо внести в раздел 10.1 Дополнения (новые требования). 6. После того, как были внесены изменения в документ, и вы готовы его завершить, убедитесь, что Вы обновили оглавление документа. 7. Составьте карту рассмотрения документа и его утверждений теми лицами, которые были определены в разделе с заинтересованными сторонами. 8. Из-за того, что документ с бизнес-требованиями является динамичным, после того, как менеджер проекта получает согласованный документ, все дополнительные, измененные или отмененные требования вносятся в 10 раздел. 9. Если вносятся изменения в документ, то необходимо обновить раздел с историей обновлений документа. 10. Документ с описанием бизнес-требований будет храниться вместе с другими документами проекта и поддерживаться в соответствии с политикой хранения документов. | ||||||||||||||||||||||||
| Расширение прав и возможностей. Масштабируемость. | Данный шаблон предоставляется в качестве ориентира для сбора базовой информации, необходимой для успешного формирования документа с описанием бизнес-требований. Руководители проекта имеют право использовать этот шаблон по мере необходимости для сбора каких-либо конкретных требований предполагаемого проекта. Количество деталей, которые содержит документ, зависит от размера и сложности проекта. В зависимости от проекта или потребностей бизнеса, требования могут быть добавлены, но не могут быть удалены. Информация по документу и согласование документа
Этот документ был утвержден в качестве официального документа с бизнес-требованиями для проекта « », и точно отражает текущее понимание бизнес-требований. После утверждения этого документа, изменения требований будет регулироваться через процесс управления изменениями, включая анализ последствий (impact analysis), проходя стадии рассмотрения и согласования.
Оглавление документа Этот документ определяет высокоуровневые требования этого проекта. Документ будет использоваться в качестве основы для следующих видов деятельности:
4.1 Обзор проекта и предпосылки4.2 Зависимости проекта4.3 Заинтересованные стороныНиже перечислены внутренние и внешние заинтересованные стороны, чьи требования представлены в этом документе: | ||||||||||||||||||||||||