1.3.1 Домены

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

1.3.2 Решения

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

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

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

1.3.3 Требования

Требование — это:

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

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

Документированное представление состояния или возможности, упомянутых в пунктах (1) и (2).

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

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

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

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

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

.1        Схема классификации решений

В рамках Руководства BABOK требования описываются в рамках следующей классификационной схемы:

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

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

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

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

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

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