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

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

Бизнес-требование может быть представлено в любом из следующих вариантов:wing способы:

  • Таблица или электронная таблица
  • Диаграмма (рабочий процесс)
  • График
  • Модель (диаграмма сущность-связь)
  • Прототип или симуляция
  • Структурированное предложение или текстовый шаблон

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

Ниже приведены шаги по написанию и организации требований в виде Бизнес-аналитик.

Шаг 1) Классифицировать требования.

  • Разместите конкретные требования к соответствующим категориям.
  • Для технических заинтересованных сторон должна быть категория технических требований, для нетехнических заинтересованных сторон должна быть общая категория требований.
  • Каждая организация должна выяснить, какая категория соответствует ее стандартам.
  • Категоризацию также можно проводить на основе их типов (функциональные или бизнес-классы). Хотя это применимо не ко всем случаям.

Шаг 2) Упорядочить требования.
Соберите и расположите требования в логическом порядке. Поэтому, когда заинтересованные стороны просматривают требования, в них легко ориентироваться, а также выявлять недостающие элементы.

Шаг 3) Подготовьте список.
Подготовьте список требований, которые должны быть рассмотрены конкретными заинтересованными сторонами.

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

Шаг 4) Используйте уникальные идентификаторы.
Если отслеживание требований друг к другу затруднено, используйте уникальные идентификаторы, чтобы упростить отслеживание.

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

Шаг 6) Подготовьте оглавление.
Создайте оглавление для всех требований. Это помогает заинтересованным сторонам легко отслеживать требования.

Шаг 7) Используйте инструменты бизнес-анализа.
Инструменты бизнес-анализа которые помогают в представлении и категоризации требований

Шаг 8) Организуйте документы требований по потокам процессов.
В документе с требованиями удалите все ненужные требования и упорядочите документы требований по потокам процессов.

Шаг 9) Составьте карту требований.
Сопоставьте собранные вами требования с конкретным этапом процесса, и это поможет проверяющим связать требования с потоком процесса.

Шаг 10) Используйте таблицу и пункты списка.
Используйте таблицу для представления complex требования. Используйте пункты списка, чтобы выделить ключевой аспект требования.

Полезные советы по написанию и представлению документа бизнес-требований

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

  • Требования к категоризации отнимают много времени, и для каждой организации может оказаться невозможным каждый раз создавать новую категорию. В целях наилучшей практики рекомендуется наличие стандартного набора категорий, который мог бы широко использоваться бизнес-аналитиками, заинтересованными сторонами, профильными экспертами и техническими группами.
  • Ваше требование должно быть подготовлено в контексте вашей аудитории. Поймите, кто является ключевыми игроками, влиятельными лицами и лицами, принимающими решения. (Заинтересованные стороны, технический персонал, разработчики и т. д.)
  • Определите одно требование за раз. Каждое требование должно быть atomIC.
  • Избегайте двусмысленности, избегая таких сокращений, как и т. д., прибл. и т. д.
  • Не ссылайтесь на требование, которое еще не определено.
  • Избегайте повторяющихся и противоречивых утверждений.
  • Прервать комplex требование на управляемые и проверяемые точки.
  • Избегайте описания того, как система будет что-то делать, упоминайте только то, что она будет делать.