Глава 1: Введение в BABOK 2.0


Ключевые слова: перевод BABOK v. 2.0. на русский язык (IIBA), бизнес-анализ, бизнес-аналитик, системный-аналитик, управление требованиями, бизнес-требования, бизнес-правила, функциональные требования, нефункциональные требования, области знаний бизнес-анализа, Свод знаний по бизнес-анализу, Business Analysis Body of Knowledge

Что такое свод знаний по бизнес-анализу (Business Analysis Body of Knowledge)?

Руководство свода знаний по бизнес-анализу (Руководство BABOK) — это всемирно признанный стандарт для практики бизнес-анализа. Руководство BABOK описывает области знаний бизнес-анализа, связанные с ними деятельности и задачи, а также навыки, необходимые для эффективного их исполнения.
Основной целью Руководства BABOK является установление границ профессии бизнес-анализа. Руководство BABOK служит основанием, с помощью которого практики могут договориться для того, чтобы обсудить работу, которую они делают, и с помощью которого могут убедиться, что они имеют навыки, позволяющие им эффективно исполнять роль, а также определяет навыки и знания, с которыми люди работают и которые используются бизнес-аналитиками. Руководство BABOK — это концепция, описывающая задачи бизнес-анализа, которые должны быть выполнены для того, чтобы понять как решение будет приносить пользу организации-спонсору. Форма этих задач, последовательность их выполнения, относительная значимость и другие аспекты могут различаться, но каждая задача способствует в некотором роде, прямо или косвенно, достижению общей цели.
В этой главе дается введение в ключевые понятия областей бизнес-анализа и описывает структуру оставшейся части Руководства BABOK. Главы со 2 по 7 определяют задачи, которые бизнес-аналитик должен быть способен выполнять. Глава 8 описывает компетенции, которые способствуют эффективному исполнению бизнес-анализа. Глава 9 описывает ряд общепринятых методов, которые поддерживают практику бизнес-анализа.

Что такое бизнес анализ?

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

Ключевые концепции

Домены

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

Решения

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

Требования

Требование — это:
1. Условие или возможность, необходимые заинтересованной стороне для решения проблемы или достижения цели.
2. Условие или возможность, которые должны быть выполнены или которыми должно обладать решение/компоненты решения для удовлетворения контракта, стандарта, спецификации или других официальных документов.
3. Документированное представление условий или возможностей, как в (1) или (2).

Как видно из этого определения, требование может быть скрытым, подразумеваемым или вытекающим из других требований, или же может быть напрямую указанным и управляемым. Одной из ключевых задач бизнес-анализа является обеспечение того, чтобы требования были видны и понятны для всех заинтересованных сторон.
Термин «требование» порождает множество дискуссий в рамках сообщества бизнес-анализа. Многие из этих дебатов сосредотачиваются на том, что следует или что не следует считать требованием, и каковы необходимые характеристики требования. Тем не менее, при изучении Руководства BABOK очень важно термин «требование» понимать в самом широком смысле. Требования включают, но не ограничиваются прошлыми, настоящими или будущими условиями и возможностями предприятия, а также описанием организационной структуры, ролей, процессов, политик, нормативов и информационных систем. Требование может характеризовать текущее или будущее состояние любого аспекта работы предприятия.
Большая часть существующей литературы по бизнес-анализу написана в предположении, что требования описывают только ИТ-систему, которую планируют внедрять. Другие определения могут также содержать в себе бизнес-функции будущего состояния организации или могут ограничивать смысл термина целями, которые стремятся достичь заинтересованные лица, а не средствами, с помощью которых эти цели достигаются. Хотя все эти различные использования термина являются разумными и оправданными, и термин, используемый руководством BABOK, включает все эти значения, они значительно уже, чем употребляемый здесь термин.
Точно так же мы не считаем, что требования анализируются на конкретном уровне детализации, а наоборот — они должны быть оценены независимо от уровня детализации с целью понимания и действий. В контексте инициативы управления бизнес-процессами, требования могут являться описанием текущих бизнес-процессов, используемых в организации. На других проектах, бизнес-аналитик может решить разрабатывать требования, описывающие текущее состояние предприятия (которое само по себе является решением текущих или прошлых потребностей бизнеса) перед тем, как рассматривать внесение в решение изменений, необходимых для удовлетворения меняющихся условий бизнеса.

Схема классификации требований
Для целей Руководства BABOK используется следующая схема классификации для описания требований:
Бизнес-требования — это высокоуровневые формулировки целей, задач и потребностей предприятия. Они описывают причины, по которым был инициирован проект, задачи, которые будут достигнуты в ходе проекта, а также метрики, которые будут использоваться для измерения его успешности. Бизнес-требования описывают потребности организации в целом, а не группы или заинтересованных в нем сторон. Они разработаны и определены на основе анализа предприятия.
Требования заинтересованных сторон — это формулирование нужд конкретного заинтересованного лица или класса заинтересованных лиц. Эти требования описывают потребности, которые описывают что заинтересованная сторона имеет и как эта заинтересованная сторона будет взаимодействовать с решением. Требования заинтересованных сторон служит в качестве моста между бизнес-требованиями и другими классами требований к решению. Они разработаны и определены на основе анализа требований.
Требования к решению описывают характеристики к решению, которые соответствуют бизнес-требованиям и требованиям заинтересованных сторон. Они разработаны и определены на основе анализа требований. Их часто делят на подкатегории, особенно в случаях, когда требования описывают программное решение:
Функциональные требования описывают поведение решения и информацию о том, чем оно будет управлять. Эти требования описывают возможности системы, которые доступны к выполнению, в части режимов работы или операций — действия или реакции конкретного ИТ-приложения.
Нефункциональные требования фиксируют условия, которые напрямую не относятся к поведению или функциональности решения, а скорее описывают условия окружающей (внешней) среды, в условиях которой решение должно сохранять эффективность и качества, которыми система должна обладать. Они также известны как требования качества или дополнительные требования. Они могут включать в себя требования, связанные с мощностью (емкостью), скоростью, безопасностью, доступностью, информационной архитектурой и пользовательским интерфейсом.
Переходные требования описывают возможности, которыми решения должно обладать для осуществления перехода из текущего состояния предприятия к желаемому (требуемому) состоянию в будущем. Эти требования статут ненужными, как только этот переход завершится. Они отличаются от других типов требований, потому что они всегда носят временный характер и потому, что они не могут быть разработаны, пока оба решения, существующее и новое, не будут определены. Как правило, они охватывают преобразование данных из существующих систем, пробелы в знаниях и квалификации, которые должны быть решены, а также другие соответствующие изменения, необходимые для достижения желаемого будущего состояния. Их разрабатывают и определяют посредством проведения оценки и валидации (проверки) решения.

Области знаний

Области знаний определяют то, что практикующему специалисту бизнес-анализа нужно понимать и какие задачи он должен быть в состоянии выполнять.
Бизнес-аналитикам, скорее всего, необходимо выполнять задачи из всех областей знаний подряд, многократно или одновременно. Задачи могут выполняться в любой последовательности при условии наличия необходимых входных данных. В принципе, работа бизнес-аналитика может начаться с любой задачи, хотя наиболее вероятными задачами будут «Определение потребностей бизнеса» (5.1) или «Оценка эффективности решения» (7.6).
Области знаний не предназначены для представления фаз в проекте. Это, конечно, возможно и допустимо переходить от выполнения анализа деятельности предприятия к анализу требований, к оценке решения и валидации деятельности, и относиться к каждому из этих мероприятий как к отдельному этапу проекта. Однако руководство BABOK этого не требует, поэтому указанные шаги не следует рассматривать в качестве готовой методологии для выполнения бизнес-анализа.
Планирование и контроль бизнес-анализа (Глава 2) — это область знаний, которая освещает как бизнес-аналитика определить какие виды деятельности необходимы для осуществления бизнес-анализа. Она охватывает идентификацию заинтересованных сторон, выбор методов бизнес-анализа, процесса, который будет использоваться для управления требованиями и оценки хода работы. Задачи в этой области знаний регулируют производительность всех других задач бизнес-анализа.
Сбор информации (Глава 3) описывает как бизнес-аналитики работают с заинтересованными сторонами для определения и понимания их потребности и опасения, а также понять условия, в которых они работают. Целью сбора информации состоит в том, чтобы были поняты истинные, лежащие в основе потребности, а не их высказанные или поверхностные пожелания.
Управление требованиями и коммуникации (Глава 4) описывает, как бизнес-аналитики управляют конфликтами, проблемами и изменениями для того, чтобы гарантировать, что заинтересованные стороны и команда проекта находятся в согласии по рамкам решения, а также как требования доводятся до заинтересованных сторон и как знания полученные бизнес-аналитиком сохраняются для использования в будущем.
Анализ предприятия (глава 5) описывает как бизнес-аналитики идентифицируют потребности бизнеса, улучшают и проясняют определение этой потребности, а также определяют границы решения, которые могут быть реально реализованы для бизнеса. Эта область знаний описывает постановку пролемы и ее анализ, разработку бизнес-кейсов, техникоэкономические обоснования и определения границ решений.
Анализ требований (Глава 6) описывает, как бизнес аналитики расставляют приоритеты и последовательно уточняют требования заинтересованных сторон и требования по решению с тем, чтобы позволить проектной команде реализовать решение, которое будте соответствовать потребностям организации-спонсору и заинтересованным сторонам. Анализ требований включает в себя анализ потребностей заинтересованных сторон для определения решений, которые отвечают этим потребностям, оценку текущего состояния бизнеса для выявления и подготовки рекомендаций по улучшению, а также верификацию и валидацию требований.
Оценка и проверка решения (Глава 7) описывает, как бизнес-аналитики оценивают предлагаемые решения, чтобы определить какое решение лучше всего подходит для подребности бизнеса, выявляют пробелы и недостатки в решениях, а также определяют определяют необходимые доработки и изменения в решении. Оценка и проверка решения также описывает, как бизнес-аналитики оценивают развернутые решения, чтобы увидеть насколько хорошо они соответствуют потребностям, дабы организация-спонсор могла оценить производительность и эффективность решения.
Базовые компетенции (Глава 8) описывает поведение, знания и другие характеристики, которые поддерживают эффективное выполенние бизнес-анализа.
knowledge_area

Задачи

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

  • Назначение задачи
  • Описание задачи
  • Входные данные
  • Диаграмма входных/выходных данных задачи
  • Требования входных данных для задачи
  • Элементы задачи
  • Методы выполнения задачи
  • Заинтересованные лица
  • Выходные данные задачи

Назначение задачи (цель)

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

Описание задачи

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

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

Входные данные для задачи

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

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

Диаграммы входных и выходных данных задачи:
task_input_output_diagrams

Требования для входных данных задач

Требования являются частным случаем как входных или выходных данных, что не должно быть неожиданно, учитывая их важность для бизнес-анализа. Они являются только входом или выходом, которые не производятся одной задачей. Требования могут быть классифицированы в несколько различных способов и могут существовать в любом из множества состояний. Когда указан в качестве входа или выхода в этом разделе задачи, следующий формат будет использоваться для обозначения классификации и состояния требования или набора требований:
Классификация требований [состояние или состояния]. Если не перечислены классификация или состояния, все или только некоторые требования могут быть использованы в качестве входа или выхода. Например, Требования [Заявленные] — означает что требования могут иметь любую классификацию, тогда как бизнес-требования — будет означать, могут быть в любом возможном состоянии (например, проверены, приоритезированы, заявлены или комбинации этих состояний).
Требования могут быть также объединены в некоторых случаях. Например, Требования [Приоритезированы и Проверены] — должны быть прочитаны, чтобы указать, что требования были приоритезированы и проверены. Требования [Приоритезированы или Проверены] — означает, что требования могут быть либо приоритезированы, либо проверены, либо одновременно приоритезированы и проверены.

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

Элементы задачи

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

Методики

Каждая задача содержит перечень соответствующих методов. Некоторые методы характерны для выполнения одной задачи, в то время как другие относятся к выполнению большого числа задач (и перечислены в Главе 9: Методы). Если конкретная задача может использовать оба вида техник, те, что описаны в Главе 9 будут перечислены в подразделе «Общие методы». Если нет подраздела, то все методы можно найти в Главе 9. Для получения дополнительной информации см. Методы (1.6).

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

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

Техники (методы или методики)

Методы содержат дополнительную информацию о различных способах, с помощью которых задача может быть выполнена, или какие различные формы могут принять выходы задачи. Задача может иметь ни одного, один или более связанных с ней методик (техник). Методика должна быть связана по меньшей мере с одной задачей.
Руководство BABOK не предписывает набор методов анализа, которые должны использоваться. Методики, описанные в данном документе — это те, которые уже продемонстрировали свою ценность и используются большинством сообщества бизнес-анализа. Бизнес-аналитики, которые знакомы с этими техниками, скорее всего, смогут эффективнее выполнять свои функции в большинстве случаев, с которыми они, вероятно, столкнуться. Однако эти методы не всегда являются лучшими возможными вариантами для использования в той или иной ситуации, и не обязательно что они эффективно могут учесть все ситуации. Точно также, маловероятно, что бизнес-аналитик будет призван демонстрировать опыт каждого метода, который определен в Руководстве BABOK.
Подмножество методов в Руководстве BABOK может описываться для широкого применения. Эти методы регулярно используются большинством бизнес-аналитиков и можно видеть иногда использование со стороны подавляющего большинства практиков и вполне вероятно, что многие, если не большинство организаций, будут ожидать от бизнес-аналитиков практические знания этих методов. Этими методами, которые попадают в эту категорию, являются:

  • Определение критериев приемки и оценки (9.1)
  • Мозговой штурм (9.3)
  • Анализ бизнес-правил (9.4)
  • Словарь данных и Глоссарий (9.5)
  • Диаграммы потоков данных (9.6)
  • Моделирование данных (9.7)
  • Анализ решений (9.8)
  • Анализ документов (9.9)
  • Интервью (9.14)
  • Метрики и Ключевые показатели эффективности (9.16)
  • Анализ нефункциональных требований (9.17)
  • Организационное моделирование (9.19)
  • Отслеживание проблемы (9.20)
  • Моделирование процессов (9.21)
  • Семинары требований (9.23)
  • Сценарии и варианты использования (9.26)

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

Цель
Определяет для чего эта техника используется и при каких обстоятельствах скорее всего, она будет применима.

Описание
Описание того, что это за техника и как она используется.

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

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

Основные компетенции (Базовые компетенции)

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

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

Другие ресурсы информации по бизнес анализу

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

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

  • Гибкая разработка (Agile)
  • Бизнес-аналитика (BI)
  • Управление бизнес-процессами
  • Бизнес-правила
  • Управление ИТ-услугами (включая ITIL)
  • Lean и Six Sigma
  • Управление организационными изменениями
  • Управление проектами
  • Управление качеством
  • Сервис-ориентированная архитектура
  • Разработка программного обеспечения (в частности, разработка требований)
  • Совершенствование процессов разработки (в том числе CMMI)
  • Контроль качества программного обеспечения
  • Стратегическое планирование
  • Проектирование пользовательского интерфейса

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


Словарь терминов по бизнес-анализу на основе BABOK

А

Актив организационного процесса (Organizational Process Asset) — Все материалы, используемые группами в организации для определения, моделирования, внедрения и поддержки своих процессов.
Активность (Activity) — Единица работы, которая выполняется как часть инициативы или процесса.
Анализ воздействия (Impact Analysis) — Оценка эффекта, который окажут предложенные изменения на участников (или их группу) процесса, проект или систему
Анализ возможностей (Opportunity Analysis) — Процесс изучения новых бизнес-возможностей для повышения эффективности организации.
Анализ документов (Document Analysis) — Метод выявления требований к существующей системе путем изучения доступной информации, документов и определения ее релевантности.
Анализ затрат и результатов (Cost Benefit Analysis) — Анализ, проводимый для сравнения и определения количества финансовых и нефинансовых затрат для создания или изменения программного решения с потенциальными полученными выгодами.
Анализ конкурентов (Competitive Analysis) — Структурированный процесс, которых охватывает ключевые характеристики индустрии для расчета долгосрочных перспектив получения прибыли и для определения приемов основных конкурентов.
Анализ накопленных знаний (Lessons Learned Process) — Техника улучшения процесса, используемая для изучения и оптимизации процесса или проекта. Сеанс анализа включает специальное собрание, в течение которого команда исследует на примере завершенной итерации что работает, не работает, что может быть улучшено и как применить новые процессы и техники в новой итерации перед ее началом.
Анализ осуществимости (Feasibility Analysis) — См. технико-экономическое обоснование (feasibility study).
Анализ отклонений (Variance Analysis) — Анализ различий между запланированным и действительным поведением для определения их величины и рекомендации действий по исправлению и профилактике системы.
Анализ первопричин (Root Cause Analysis) — Структурированное изучение установленной проблемы для понимания лежащих в основе причин.
Анализ принятия решений (Decision Analysis) — Подход к принятию решений, который изучает и моделирует возможные последствия различных решений. Такой тип анализа помогает в принятии оптимального решения в условиях неопределенности.
Анализ просчетов (Gap Analysis) — Сравнение текущего и желаемого состояния организации в целях определения недостатков, над которыми предстоит работать.
Анализ силового поля (Force Field Analysis) — Графический метод изображения центров влияния, которые способствуют и/или препятствуют изменениям. Включает определение центров влияния и оценку степени влияния каждого из них. [Также известен как анализ поля сил]
Анализ участников процесса (Stakeholder Analysis) — Работа по идентификации участников процесса, на которых может повлиять предлагаемое решение, оценка их интересов и возможного участия.
Аналитик (Analyst) — Общее название роли человека, который отвечает за разработку и поддержку требований. Также встречаются названия: бизнес-аналитик (business analyst), бизнес-интегратор, аналитик требований, инженер требований и системный аналитик (systems analyst).
Анкета (Questionnaire) — См. анкетирование.
Анкетирование (Survey) — Предоставление набора письменных вопросов участникам процесса с целью сбора ответов от большой группы людей в относительно короткий промежуток времени.
Архитектура предприятия (Enterprise Architecture) — Описание бизнес-процессов организации, программного и аппаратного обеспечения, людей, операций и проектов, а также взаимодействий между ними.
Ассоциация (Association) — Связь между двумя элементами или объектами в диаграмме.
Атрибут (Attribute) — Элемент данных определенного типа, который описывает информацию, которая ассоциируется с понятием или сущностью.
Атрибут требований (Requirements Attribute) — Метаданные, которые относятся к требованию и используются в разработке и управлении требованиями.
Атрибуты качества (Quality Attributes) — Подмножество нефункциональных требований, которые описывают свойства работы, разработки и развертывания программного обеспечения (например, производительность, безопасность, удобство использования, портативность, проверяемость).
Аттестация (Validation) — Процесс проверки продукта на соответствие требованиям и предполагаемому использованию. Аттестация обеспечивает построение правильного решения. См. также аттестация требований (requirements validation).
Аттестация требований (Requirements Validation) — Работа, проводимая для того, чтобы удостовериться, что названные требования поддерживают цели и задачи бизнеса и соответствуют им.
Аттестованные требования (Validated Requirements) — Требования, которые продемонстрировали бизнес-ценность и согласуются с бизнес-целями и задачами.

Б

Бенчмаркинг или Контрольное тестирование (Benchmarkning) — Сравнение стоимости, времени, качества или других показателей процесса или системы с показателями лидирующими организациями в той же области или другой области с целью улучшения данных показателей путем применения «у себя» лучших практик лидирующих организаций.
Бизнес-анализ (Business Analysis) — Набор задач и техник, который используется для работы в качестве посредника между участниками процесса (stakeholders) для понимания структуры организации, ее стандартов и процессов и выработки решений (solutions), которые помогут организации добиться ее целей.
Бизнес-аналитик (Business Analyst) — Человек, который проводит бизнес-анализ.
Бизнес-архитектура (Business Architecture) — Подраздел архитектуры предприятия, который определяет текущее и будущее состояние организации, включая ее стратегию, цели и задачи. Бизнес-архитектура исследует внутреннюю среду через процесс или в функциональном срезе, а также внешнюю среду, в которой оперирует бизнес и участников процесса, которые затрагиваются в ходе деятельности.
Бизнес-область (Business Domain) — См. область (domain).
Бизнес-ограничения (Business Constraints) — Ограничения, которые накладываются на проект решения организацией-заказчиком. Бизнес-ограничения описывают ограничения на доступные решения или аспекты, которые не подлежат изменению при внедрении нового решения. См. также технические ограничения.
Бизнес-потребность (Business Need) — Тип высокоуровневого бизнес-требования, который определяет бизнес-задачу или влияние программного решения на рабочую среду.
Бизнес-правило (Business Rule) — Специальное, исполнимое, тестируемое указание, которое находится под контролем бизнеса и поддерживает деловую политику.
Бизнес-процесс (Business Process) — Набор определенных специальных или упорядоченных действий, которые выполняются на постоянной основе в организации. Процессы начинаются с событий и могут иметь несколько вариантов окончания. Успешное окончание процесса приносит пользу одному или более его участнику.
Бизнес-событие (Business Event) — Событие в системе, инициированное людьми.
Бизнес-требование (Business Requirement) — Высокоуровневое бизнес-обоснование, которое должно помочь организации поднять прибыль, снизить затраты, улучшить обслуживание или соответствовать регуляторным требованиям.
Бизнес-цель (Business Goal) — Состояние или условие, которое бизнес должен удовлетворить для достижения своего видения.
Бэклог продукта (Product Backlog) — Набор историй (user stories), требований или свойств, которые были определены в качестве кандидатов на разработку, приоретизированы и оценены.

В

Верификация (Verification) — Процесс проверки соответствия поставляемого на определенной стадии продукта требованиям к предыдущей стадии. Верификация обеспечивает создание правильного решения. См. также верификация требований (requirements verification).
Верификация требований (Requirements Verification) — Работа, проводимая для того, чтобы определить, что названные требования определены верно и с приемлемым уровнем качества. Это гарантирует, что требования полностью выявлены и структурированы для использования командой разработки во время проектирования, собственно разработки и внедрения решения.
Верифицированные требования (Verified Requirements) — Требования, которые продемонстрировали такие качественные характеристики, как согласованность, полнота, целостность, корректность, осуществимость, модифицируемость, непротиворечивость и проверяемость.
Вертикальный прототип (Vertical Prototype) — Прототип, который углубляется в подробности интерфейса и/или функционала.
Вложенные прецеденты использования (Included Use Cases) — Прецеденты использования, состоящие из общего набора шагов, которые используются многими прецедентами использования.
Внешние интерфейсы (External Interfaces) — Интерфейсы с другими системами (включая аппаратное и программное обеспечение и людей), с которыми будет взаимодействовать предлагаемая система.
Временное событие (Temporal Event) — Системный триггер, запускаемый автоматически в определенное время.
Временные ограничения (Timebox) — Фиксированный период времени для достижения желаемого результата.
Второстепенное действующее лицо (Secondary Actor) — Действующее лицо, которое участвует, но не инициирует прецеденты использования.
Выделение требований (Requirements Allocation) — Процесс распределения требований по подсистемам и компонентам (люди, аппаратное и программное обеспечение).
Высказанные требования (Stated Requirements) — Требования, высказанные участником процесса, которые не были проанализированы, верифицированы и аттестованы. Часто они отображают скорее желания участника процесса, чем актуальные потребности.
Выявление (Elicitation) — Деятельности по разработке требований, которая определяет источники требований, а затем использует техники выявления (например, интервью, прототипы, вспомогательные семинары, изучение документации) требований из этих источников.

Г

Глоссарий, словарь (Glossary) — Список определений бизнес-терминов и понятий, относящихся к разрабатываемому решению.
Горизонтальный прототип (Horizontal Prototype) — Прототип, который демонстрирует функционал системы в неглубоком и, возможно, широком срезе, но обычно не пригоден к фактическому использованию и взаимодействию.

Д

Действующая норма (Operative Rule) — Бизнес-правило, которое является частью внутренней политики организации и служит в качестве инструкции для людей, работающих в бизнесе. Оно может обязывать людей совершать действия, предотвращать их или описывать условия, в которых действие необходимо предпринять.
Действующее лицо (Actor) — Роль, которая принадлежит человеку или машине/программе и взаимодействует с системой.
Декомпозиция (Decomposition) — Техника, при которой проблема разбивается на компоненты для облегчения последующего анализа и понимания этих компонентов.
Декомпозиция работ (Work Breakdown Structure) — Иерархическая декомпозиция работ по поставке, подлежащих выполнению проектной командой для достижений задач проекта и создания требуемых компонентов поставки. Она организует и определяет рамки проекта.
Деловая политика (Business Policy) - Директива, которая не призывает к конкретным действиям и поддерживает бизнес-цель.
Дерево решений (Decision Tree) — Аналитическая модель, которая является альтернативой таблице решений и иллюстрирует последовательность условия и действия.
Дефект (Defect) — Недостаток продукта или сервиса, который понижает его качество или отличается от желаемого атрибута, состояния или функционала. См. также дефект требований.
Дефект требований (Requirements Defect) — Ошибка в требованиях, вызванная неправильными, неполными, отсутствующими или конфликтующими требованиями.
Диаграмма автомата (State Machine Diagram) — См. диаграмма состояний (state diagram).
Диаграмма активности (Activity Diagram) — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью англ. activity понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий англ. action, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.
Диаграмма изменения состояний (State Transition Diagram) — См. диаграмма состояний (state diagram).
Диаграмма последовательности (Sequence Diagram) — Тип диаграммы, которая показывает взаимодействующие объекты и сообщения, которыми они обмениваются.
Диаграмма потока данных (Data Flow Diagram или DFD) — Аналитическая модель, которая иллюстрирует происходящие процессы наряду с потоками данных внутрь и наружу этих процессов.
Диаграмма прецедента использования (Use Case Diagram) — Тип диаграммы, определенный языком моделирования UML, который охватывает всех действующих лиц и прецеденты использования, связанные с системой или продуктом.
Диаграмма причин и следствий (Cause and Effect Diagram) — См. диаграмма причинно-следственных связей (fishbone diagram).
Диаграмма причинно-следственных связей (Fishbone Diagram) — Техника, которая используется в анализе первопричин рассматриваемой проблемы и отношений между ними [первопричинами].
Диаграмма состояний (State Diagram) — Аналитическая модель, которая показывает жизненный цикл сущности данных или класса.
Диаграмма сущностей и связей (Entity-Relationship Diagram) — Графическое представление сущностей, связанных с выбранной проблемной областью, отношений между ними и их атрибутов.
Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.
Диаграммы деятельности позволяют моделировать сложный жизненный цикл объекта, с переходами из одного состояния (деятельности) в другое.
Документ о пользовательских требованиях (User Requirements Document) — Документ о требованиях, рассчитанный на аудиторию пользователей, описывающий пользовательские требования и влияние ожидаемых изменений на пользователей.
Документ о требованиях (Requirements Document) — См. пакет требований (requirements package).
Документальный источник бизнес-требований (Business Requirements Document) — Пакет требований, который описывает бизнес-требования и требования участников процесса (документируется скорее требования бизнеса, чем требования к бизнесу)
Допущение (Assumption) — Фактор влияния, который считается верным, но не был проверен.
Дорожка (Swimlane) — Горизонтальная или вертикальная секция в модели процессов, которая демонстрирует, какие активности выполняются отдельным действующим лицом или ролью.

З

Задача (Goal) — См. бизнес-задача (business goal).
Задача (Objective) — Цель (target) или метрика, к которой стремится человек или организация на пути к достижению глобальной цели (goal).
Запрос информации (Request For Information) — Документ о требованиях, который представляет собой запрос, который направляется поставщику для получения оценки предлагаемого процесса или продукта. Запрос информации готовится в случае, когда организация стремится сравнить различные альтернативы или испытывает сомнения относительно имеющихся вариантов.
Запрос о цене (Request For Quote) — Неофициальный запрос предложений от поставщиков.
Запрос предложения (Request For Proposal) — Документ о требованиях, который готовится в случае, когда организация ждет официальных предложений от поставщиков. Запрос предложения обычно требует, чтоб предложения были внесены в соответствии с неким процессом и с использованием запечатанных заявок, которые оцениваются с помощью формальной методологии.
Заседание по выявлению требований (Discovery Session) — См. семинар по сбору требований.
Заседание по выявлению требований (Requirements Discovery Session) — См. семинар по сбору требований (requirements workshop).

И

Иерархия диалогов (Dialog Hierarchy) — Аналитическая модель, которая отображает иерархическую структуру диалогов пользовательских интерфейсов.
Индикатор (Indicator) — Особая числовая мера, которая показывает прогресс в достижении воздействия, результат, действие или исходные данные. См. также метрика (metric).
Инженер по разработке ПО (Software Engineer) — См. разработчик (developer).
Инициатива (Initiative) — Любое усилие, которое предпринимается для достижения определенной цели или задачи.
Инкрементальная поставка (Incremental Delivery) — Создание рабочего программного обеспечения посредством некоторого количества релизов, когда весь продукт поставляется порциями.
Инспекция (Inspection) - Формальный вид экспертной оценки с использованием предопределенного и задокументированного процесса, особых участников и методов отслеживания дефектов и процесса в целом. См. также сквозной структурный контроль (structured walkthrough).
Инструмент управления требованиями (Requirements Management Tool) — Программное обеспечение, которое позволяет хранить информацию о требованиях в базе данных, фиксировать атрибуты и связи требований и облегчает отчетность.
Интервью (Interview) — Систематический подход к получению информации от человека или группы людей в неформальной или формальной обстановке посредством постановки вопросов и документирования ответов на них.
Интерфейс (Interface) — Канал передачи информации между двумя людьми или человеком и системой.
Информационный объект (Data Entity) — Сгруппированная для хранения в системе информация. Объектами могут быть люди, роли, места, вещи, организации, события, понятия или документы.
Итерация (Iteration) — Процесс, в котором продукт поставки (или все решение) разрабатывается постепенно. Каждая итерация — это самодостаточный “мини-проект”, в котором предпринимается весь набор действий для разработки продукта поставки или его фрагмента. Каждая итерация включает планирование и выполнение работы командой, а также проверку качества и завершенности. Итерация может содержать вложенные итерации. Например, итерация разработки требований включает сбор, анализ, документирование и проверку.
Итерация требований (Requirements Iteration) — Итерация, которая определяет требования для некоторой части решения. Например, итерация требований будет включать определение части продукта, на которой предстоит сфокусироваться и источников требований для нее, определение участников процесса, планирование и проведение сбора требований у них, документирование и проверка требований.

К

Карта диалогов (Dialog Map) — Аналитическая модель, которая иллюстрирует архитектуру пользовательских интерфейсов системы.
Карта отношений (Relationship Map) — Бизнес-модель, которая иллюстрирует контекст организации в виде отношений, существующих внутри нее, с внешними клиентами и поставщиками.
Карта процесса (Process Map) — Бизнес-модель, которая показывает бизнес-процесс в виде шагов, а также входящие и исходящие потоки в функциях, организациях или рабочих ролях.
Качество (Quality) — Степень соответствия набора характеристик требованиям.
Качество требований (Requirements Quality) — См. аттестация требований (requirements validation) и верификация требований (requirements verification).
Класс (Class) — Дескриптор (описатель) для набора объектов системы с одинаковыми атрибутами, операциями, связями и поведением. Класс представляет понятие в разрабатываемой системе. При использовании в аналитической модели класс также обычно относится к сущности реального мира.
Код (Code) — Система программируемых формулировок, символов и правил, которые используются для передачи инструкций компьютеру.
Количество элементов (Cardinality) - Количество экземпляров одной сущности в модели данных, которые связаны с другой сущностью. Количество экземпляров изображается на модели посредством специальной нотации, цифр (например, 1) или букв (например, М означает много)
Коммерческое коробочное программное обеспечение (Commercial-off-the-Shelf Software) — Программное обеспечение, разрабатываемое и направленное на конкретные рынки.
Конечный пользователь (End User) — Человек или система, которые напрямую взаимодействуют с решением. Конечные пользователи могут быть людьми, а также системами, которые отправляют или получают данные из системы.
Контекстная диаграмма (Context Diagram) — Аналитическая модель, которая иллюстрирует границы продукта, показывая систему в окружении внешних сущностей (людей и систем), которые обмениваются данными с системой.
Контроль качества (Quality Assurance) — Действия, которые выполняются для обеспечения того, чтобы был поставлен продукт, соответствующий заданному уровню качества.
Контрольный список (Checklist) — Техника контроля качества. Может включать стандартный набор качественных характеристик, которые проверяются для верификации и валидации требований или специально разработаны, чтобы охватить относящиеся к проекту вопросы.

М

Матрица прослеживаемости требований (Requirements Trace Matrix) — Матрица, которая используется для прослеживания отношений между требованиями. Каждый столбец в матрице предоставляет информацию о требованиях, связанные проекты или компоненты проекты.
Менеджер проекта (Project Manager) — Участник процесса, назначенный организацией-исполнителем для управления работами по достижению проектных задач.
Метаданные (Metadata) — Информация, которая используется для понимания контекста и верности данных, записанных в системе.
Методология (Methodology) — Набор процессов, правил, шаблонов и рабочих методов, которые предписывают, как проводится бизнес-анализ, разработка и реализация решения в отдельно взятом контексте.
Методология управления на основе изменений (Change-driven Methodology) — Методология, которая фокусируется на быстрой разработке решения в инкрементальной манере и на прямом вовлечении участников проекта (stakeholders) для получения обратной связи по производительности решения.
Методология, основанная на плане (Plan-driven Methodology) — Любая методология, которая делает акцент на планировании и формальном документировании процессов, используемых для выполнения проекта, и результатов проекта.
Метрика (Metric) — Поддающийся количественному измерению уровень индикатора, которого организация хочет добиться в определенный момент времени.
Модель (Model) — Упрощенное представление действительности, которое используется для передачи информации определенной аудитории для обеспечения анализа, коммуникации и понимания.
Модель бизнес-контекста (Business Domain Model) — Концептуальный взгляд на все предприятие или его часть, который фокусируется на продуктах, поставках и событиях, которые важны организации. Модель полезна для оценки масштаба решения совместно с участниками бизнес-процесса и техническими специалистами. См. также модель.
Модель данных (Data Model) — Аналитическая модель, которая изображает логическую структуру данных, независимо от организации данных или механизмов их хранения.
Модель классов (Class Model) — Тип модели данных, который изображает информационные группы в виде классов.
Модель процесса (Process Model) — Визуальная модель или представление последовательного потока и управляющей логики для набора связанных активностей или действий.
Модель рамок (Scope Model) — Модель, которая определяет границы бизнес-области или решения.
Модель требований (Requirements Model) — Представление требований с помощью текста и диаграмм. Модели требований могут также называться моделями пользовательских требований или аналитическими моделями и могут дополнять текстовые спецификации требований.
Мозговой штурм (Brainstorming) — Тип командной работы, нацеленный на поиск широкого и разнообразного набора вариантов и идей. При этом практикуется быстрая выработка идей без критического их оценивания.
Мониторинг (Monitoring) — Непрерывный процесс сбора данных для определения того, насколько хорошо реализовано решение по сравнению с ожидаемыми результатами. См. также метрика (metric) и индикатор (indicator).

Н

Наблюдение (Observation) — Выявление требований путем наблюдения и оценки рабочей среды участника процесса.
Нефункциональные требования (Non-functional Requirements) - Атрибуты качества, ограничения в проектировании, реализации или внешние интерфейсы, которые относятся к продукту.

О

Область (Domain) — Область знаний, которая анализируется.
Область знаний (Knowledge Area) — Группа связанных между собой задач, которые обеспечивают ключевую функцию бизнес-анализа.
Объектно-ориентирование моделирование (Object Oriented Modeling) — Подход к разработке программного обеспечения, в котором ПО состоит из компонентов, включающих группы данных и функций, которые могут наследовать поведение и атрибуты от других компонентов. Последние также могут коммуницировать между собой. В некоторых организациях этот подход используется в управления бизнесом для описания и оформления логических компонентов бизнеса.
Ограничение (Constraint) — Описание любых ограничений, которые накладываются на решение и не приносят выгоду бизнесу или участникам процесса.
Одноразовый прототип (Throw-away Prototype) — Прототип, который используется для быстрого определения и уточнения требований к интерфейсу с использованием простых инструментов (иногда даже бумаги и карандаша). Обычно он не используется в дальнейшей разработке системы.
Ожидаемый результат (Desired Outcome) — Польза, которую принесет бизнесу удовлетворение некой потребности, а также конечное состояние, которого желают достичь участники процесса.
Оперативная поддержка (Operational Support) — Участник процесса, который помогает поддерживать решение в рабочем состоянии, предоставляя поддержку конечным пользователям (тренеры, служба техподдержки) или поддерживая саму систему (сетевые и другие службы поддержки).
Организационное моделирование (Organization Modeling) — Аналитическая техника, которая используется для описания ролей, сфер ответственности и отчетных структур, которые существуют в организации.
Организация (Organization) — Автономная единица предприятия, управляемая человеком или советом с четко определенными границами, которая работает для достижения общих целей и задач. Организации функционируют на постоянной основе в отличие от подразделений или проектных команд, которые могут быть расформированы после достижения поставленной задачи.
Основная версия требований (Baseline) — Зафиксированный в определенный момент времени набор требований, который был просмотрен, согласован и служит основой для дальнейшей разработки.
Отношение (Relationship) — Определенная связь между понятиями, классами или сущностями. Отношения обычно имеют название и мощность (количество элементов).
Оценка (Evaluation) — Систематическое и объективное оценивание решения для определения его состояния и эффективности в выполнении задач на протяжении некоторого времени и для нахождения путей улучшения решения для более качественного выполнения задач. См. также метрика, индикатор и мониторинг.
Оценка готовности организации (Organizational Readiness Assessment) — Оценка, которая описывает готовность участников процесса использовать решение эффективно и принять изменения, связанные с ним.

П

Пакет требований (Requirements Package) — Набор требований, сгруппированных в документе или презентации для общения с участниками процесса.
Переходные требования (Transition Requirement) — Классификация требований, которые описывают характеристики решения, необходимые для обеспечения перехода предприятия из текущего состояния в желаемое, но ненужные после завершения перехода.
План бизнес-анализа (Business Analysis Plan) — Описание запланированных действий, которые будет осуществлять бизнес-аналитик для выполнения своей работы в рамках отдельной инициативы.
План коммуникаций в бизнес-анализе (Business Analysis Communication Plan) — Описание типов коммуникации, которые осуществляет бизнес-аналитик в процессе бизнес-анализа, стороны-участники и формы, которые может принимать коммуникация.
План управления требованиями (Requirements Management Plan) — Описание процесса управления требованиями.
Подразделение организации (Organizational Unit) — Любая группа людей, связанных между собой в контексте организации или предприятия.
Подход к бизнес-анализу (Business Analysis Approach) — Набор процессов, шаблонов и видов деятельности, которые используются для проведения бизнес-анализа в особом контексте.
Пользователь (User) — Участник процесса, лицо, устройство или система, которые прямо или косвенно взаимодействует с системой.
Пользовательская история (User Story) — Высокоуровневое, неформальное, короткое описание характеристики решения, которая приносит выгоду участнику процесса. Пользовательская история обычно изложена в одном-двух предложениях и предоставляет минимум информации, необходимый разработчику для оценки работы.
Пользовательское требование (User Requirement) — См. требование участника процесса (stakeholder requirement).
Поставщик (Supplier) — Участник процесса, который предоставляет продукты или услуги организации.
Постановка задачи (Problem Statement) — Краткая формулировка или абзац, который описывает проблему в текущем виде и объясняет, как должно выглядеть успешное решение.
Потребитель (Customer) — Участник процесса (stakeholder), который пользуется продуктами или услугами, предоставляемые организацией.
Потребность (Need) — См. бизнес-потребность (business need).
Предельный объем ответственности (Span of Control) — Количество сотрудников, за которых прямо или косвенно отвечает менеджер.
Предприятие (Enterprise) — Подразделение, организация или группа организаций, которые разделяют общие цели и сотрудничают для производства продуктов и/или предоставления услуг потребителям.
Прецедент использования (Use Case) — Аналитическая модель, описывающая задачи, которые будет выполнять система для действующих лиц и цели, которые она будет достигать в процессе.
Приоретизация (Prioritization) — Процесс определения относительной важности ряда пунктов для назначения им порядка выполнения или рассмотрения.
Продукт (Product) — Решение или его компонент, которые являются результатом проекта.
Продукт поставки (Deliverable) — Любой уникальный и поддающийся проверке продукт или сервис, который должна поставить третья сторона.
Проект (Project) — Временное предприятие по созданию уникального продукта, сервиса или результата.
Проектные ограничения (Design Constraints) — Требования к ПО, которые ограничивают возможности выбора проектировщика системы.
Прослеживаемость (Traceability) — См. прослеживаемость требований (requirements traceability).
Прослеживаемость требований (Requirements Traceability) — Способность определить и задокументировать происхождение каждого требования, включая его источник (обратная прослеживаемость), назначение (прямая прослеживаемость) и связь с другими требованиями.
Прототип (Prototype) — Частичная или предварительная версия системы.
Процесс (Process) — См. бизнес-процесс.

Р

Рабочий продукт (Work Product) — Документ или набор заметок или диаграмм, которые использует бизнес-аналитик в процессе разработки требований.
Разработчик (Developer) — Ответственный за создание программного обеспечения. В область знаний разработчика входят языки программирования, практики и компоненты приложения.
Рамки (Scope) — Область, которая относится к отдельно взятому виду деятельности или теме. См. также рамки проекта (project scope) и рамки решения (solution scope).
Рамки продукта (Product Scope) — Свойства и функции, которые характеризуют продукт, сервис или результат.
Рамки проекта (Project Scope) — Работа, которая должна быть выполнена для поставки продукта, сервиса или результата с особыми свойствами и функциями. См. также рамки.
Рамки решения (Solution Scope) — Набор характеристик, которыми должно обладать решения для удовлетворения бизнес-потребности. См. также рамки (scope).
Раскадровка (Storyboard) — См. иерархия диалогов (dialog hierarchy) и карта диалогов (dialog map).
Распределение (Allocation) — См. Распределение требований.
Регулятор (Regulator) — Участник процесса с юридическими или административными полномочиями, ответственный за решение или процесс его разработки.
Рентабельность инвестиций (Return on Investment) — Мера прибыльности проекта или инвестиции.
Репозиторий (Repository) — Физическое или виртуальное средство хранения и доступа к информации по определенной теме.
Ретроспектива (Retrospective) — См. анализ накопленных знаний (lessons learned process).
Решение (Solution) — Решение удовлетворяет бизнес-потребность, решая проблему или позволяя извлечь выгоду из возможности.
Риск (Risk) — Неопределенное событие или условие, которое в случае наступления затронет цели или задачи предложенного изменения.

С

Семинар по извлечению требований (Elicitation Workshop) — См. семинар по сбору требований.
Семинар по сбору требований (Requirements Workshop) — Структурированное обсуждение, в котором тщательно отобранная группа участников работает совместно над определением и/или уточнением требований под руководством квалифицированного нейтрального посредника.
Система (System) — Набор взаимосвязанных элементов, которые взаимодействуют для выполнения задачи. Элементы системы могут включать аппаратное и программное обеспечение, а также людей. Одна система может быть элементом (подсистемой) другой системы.
Сквозной контроль (Walkthrough) — Тип экспертной оценки, в которой участники представляют, обсуждают и углубляются в продукт, чтоб найти ошибки. Сквозной контроль документации о требованиях используется для проверки корректности требований. См. также сквозной контроль (structured walkthrough).
Сквозной структурный контроль (Structured Walkthrough) — Организованная экспертная оценка элемента поставки, задача которой — поиск ошибок и упущений. Является формой контроля качества (quality assurance).
Словарь данных (Data Dictionary) — Аналитическая модель, описывающая структуры данных и атрибуты системы.
Служба (Service) — Работа, которая выполняется от лица других действующих лиц.
Событие (Event) — Нечто происходящее, на что подразделение, система или процесс должны отреагировать.
Совет управлениями изменений (Change Control Board) — Небольшая группа участников процесса, которые будут принимать решения в отношении поддержки и управления требованиями.
Спецификация программного обеспечения/требований к системе (Software/Systems Requirements Specification) — Документ о требованиях, который пишется в первую очередь для экспертов по внедрению и описывает функциональные и нефункциональные требования.
Список, роли и ответственность участников процесса (Stakeholder List, Roles, and Responsibility Designation) — Перечисление участников процесса, которых затрагивает бизнес-потребность или предлагаемое решение и описание их участия в проекте или другой инициативе.
Спонсор (Sponsor) — Участник процесса, который санкционирует и делает официальной разработку продукта, заключая контракт или оплачивая проект.
Способность (Capability) — Свойство организации, которое позволяет ей достигать бизнес-цели или задачи.
Стратегия снижения рисков (Risk Mitigation Strategy) — См. стратегия снижения рисков требований (requirements risk mitigation strategy).
Стратегия снижения рисков требований (Requirements Risk Mitigation Strategy) — Анализ рисков связанных с требованиями, который ранжирует риски и определяет действия по избеганию или сокращению этих рисков.
Структурное правило (Structural Rule) — Структурные правила определяют, что верно или неверно в отношении определенных категорий. Они описывают категоризации, которые могут изменяться с течением времени.
Сценарий (Scenario) — Аналитическая модель, которая описывает серию действий или задач, которые отвечают на событие. Каждый сценарий — это случай прецедента использования (instance of a use case).
SWOT-анализ (SWOT Analysis) — Аббревиатура от “преимущества, недостатки, возможности и угрозы” (Strengths, Weaknesses, Opportunities and Threats). Модель, используемая для понимания факторов влияния и того, как они могут повлиять на инициативу.

Т

Таблица реакции на события (Event Response Table) — Аналитическая модель в табличной форме, которая определяет события (т.е. входящие сигналы, которые стимулируют систему и вызывают в ней некие функции) и ответы на них.
Таблицы решений (Decision Tables) — Аналитическая модель, которая определяет комплексные бизнес правила или логику в более легкой для восприятия табличной форме, указывает все возможные условия и действия, которые необходимо принять во внимание в бизнес правилах.
Тест на приемлемость для пользователя (User Acceptance Test) — Тестовый случай, применяемый пользователями для определения приемлемости системы. Каждый тестовый случай описывает набор входных данных и ожидаемых результатов.
Тестировщик (Tester) — Участник процесса, ответственный за оценку качества программного приложения и обнаружение дефектов в нем.
Тесты по методу «черного ящика» (Black Box Tests) — Тесты, которые не принимают во внимание внутреннее устройство программного продукта. Эти тесты учитывают только ожидаемые входные данные и прогнозируемые выходные.
Техника (Technique) — Способ выполнения задачи бизнес-аналитиком или описание особой формы, которую приобретает конечный результат выполнения.
Технико-экономическое обоснование (Feasibility Study) — Оценка предлагаемых альтернатив для определения их технической осуществимости с учетом ограничений организации и выгод, которые они принесут организации.
Технические ограничения (Technical Constraints) — Ограничения, которые накладываются на проект решения технологиями, используемыми для его разработки. См. также бизнес-ограничение (business constraint).
Требование (Requirement) — 1. Условие или способность, которые необходимы участнику процесса для разрешения проблемы или достижения цели. 2. Условие или способность, которые должны быть удовлетворены или обеспечены решением или компонентом решения в соответствии со стандартом, спецификацией или другим официальным документом. 3. Документальное представление условия или способности из пунктов 1 или 2.
Требование к решению (Solution Requirement) — Характеристика решения, которая удовлетворяет требования бизнеса и участника процесса. Требования могут быть функциональными и нефункциональными.
Требование участника процесса (Stakeholder Requirement) — Формулировка потребностей определенного участника процесса или группы участников. Кроме потребности описывается также способ взаимодействия участника процесса с решением. Требования участников процесса служат мостиком между бизнес-требованиями и различными категориями требований к решению.

У

Универсальный язык моделирования (Unified Modeling Language) — Не запатентованный язык моделирования и спецификаций, который используется для подробного описания, визуализации и документирования элементов поставки в объектно-ориентированных преимущественно программных системах.
Управление требованиями (Requirements Management) — Виды деятельности, которые контролируют разработку требований, включая изменение требований, определение их атрибутов и прослеживаемость требований.
Устав проекта (Project Charter) — Документ, составленный инициатором проекта или спонсором, который формально подтверждает существование проекта и наделяет менеджера проекта правами использовать ресурсы организации в проектной деятельности.
Утверждение требований (Requirements Signoff) — Официальное утверждение набора требований спонсором или другим лицом, принимающим решения.
Участник процесса / стейкхолдер (Stakeholder) — Группа или человек с интересами, которые могут быть затронуты решением или попасть под его влияние.

Ф

Факультативность (Optionality) — Определение того, является ли связь между сущностями в модели данных обязательной. Факультативность показывается на модели данных с помощью специальных обозначений.
Финансово-экономическое обоснование (Business Case) — Оценка стоимости и выгод от предложенной инициативы.
Фокус-группа (Focus Group) — Способ получения мыслей и оценок относительно определенного продукта, сервиса или возможности в процессе группового обсуждения. Участники делятся своими впечатлениями, предпочтениями и потребностями, ход обсуждения управляется модератором.
Формулировка видения продукта (Product Vision Statement) — Краткая формулировка или абзац, который описывает что, кому и зачем нужно воплотить в продукте с точки зрения бизнеса.
Функциональная совместимость (Interoperability) — Способность систем коммуницировать посредством обмена данными или сервисами.
Функциональные требования (Functional Requirements) — Возможности продукта, функции, которые должен выполнять продукт для пользователей.
Функция (Feature) — Пакет связанного и видимого функционала, который должен разрабатываться в соответствии с бизнес-целями и задачами. Каждая функция — это набор логически связанных функциональных или нефункциональных требований, описанных в общих чертах.

Э

Эволюционный прототип (Evolutionary Prototype) — Прототип, который постоянно совершенствуется и обновляется на основании обратной связи, полученной от пользователей.
Экспериментальный прототип (Exploratory Prototype) — Прототип, который разработан для исследования или проверки требований.
Эксперт (Subject Matter Expert) — Участник процесса с определенным опытом и знаниями в аспекте проблемной области, альтернативах или компонентах потенциального решения.
Эксперт в области знаний (Domain Subject Matter Expert) — Человек со специальными знаниями и опытом в изучаемой предметной области или сфере деятельности.
Эксперт по реализации (Implementation Subject Matter Expert) — Участник процесса, который отвечает за проектирование, разработку и реализацию изменений, описанных в требованиях, и имеет специальные знания по разработке одного или более компонентов.
Экспертная оценка (Peer Review) — Техника проверки, в которую входит оценка части работы небольшой группой участников процесса для поиска ошибок и улучшения ее качества.


Глоссарий (english)

Activity Diagram — A model that illustrates the flow of processes and/or complex use cases by showing each activity along with information flows and concurrent activities. Steps can be superimposed onto horizontal swimlanes for the roles that perform the steps.
Activity — A unit of work performed as part of an initiative or process.
Actor(s) — The human and nonhuman roles that interact with the system.
Allocation — See requirements allocation.
Analyst — A generic name for a role with the responsibilities of developing and managing requirements. Other names include business analyst, business integrator, requirements analyst, requirements engineer, and systems analyst.
Association - A link between two elements or objects in a diagram.
Assumption - Assumptions are influencing factors that are believed to be true but have not been confirmed to be accurate.
Attribute - A data element with a specified data type that describes information associated with a concept or entity.
Baseline - A point-in-time view of requirements that have been reviewed and agreed upon to serve as a basis for further development.
Benchmarking - A comparison of a process or system’s cost, time, quality, or other metrics to those of leading peer organizations to identify opportunities for improvement.
Black Box Tests — Tests written without regard to how the software is implemented. These tests show only what the expected input and outputs will be.
Brainstorming — Brainstorming is a team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.
Business Analysis — Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies and operations of an organization, and recommend solutions that enable the organization to achieve its goals.
Business Analysis Approach — The set of processes, templates, and activities that will be used to perform business analysis in a specific context.
Business Analysis Communication Plan — A description of the types of communication the business analyst will perform during business analysis, the recipients of those communications, and the form in which communication should occur.
Business Analysis Plan — A description of the planned activities that the business analyst will execute in order to perform the business analysis work involved in a specific initiative.
Business Analyst — A practitioner of business analysis.
Business Architecture — A subset of the enterprise architecture that defines an organization’s current and future state, including its strategy, its goals and objectives, the internal environment through a process or functional view, the external environment in which the business operates, and the stakeholders affected by the organization’s activities.
Business Case — An assessment of the costs and benefits associated with a proposed initiative.
Business Constraint(s) — Business constraints are limitations placed on the solution design by the organization that needs the solution. Business constraints describe limitations on available solutions, or an aspect of the current state that cannot be changed by the deployment of the new solution. See also technical constraint.
Business Domain — See domain.
Business Domain Model — A conceptual view of all or part of an enterprise focusing on products, deliverables and events that are important to the mission of the organization. The domain model is useful to validate the solution scope with the business and technical stakeholders. See also model.
Business Event — A system trigger that is initiated by humans.
Business Goal — A state or condition the business must satisfy to reach its vision.
Business Need(s) — A type of high-level business requirement that is a statement of a business objective, or an impact the solution should have on its environment.
Business Policy — A business policy is a non-actionable directive that supports a business goal.
Business Process — A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization. Processes are triggered by events and may have multiple possible outcomes. A successful outcome of a process will deliver value to one or more stakeholders.
Business Requirement — A higher level business rationale that, when addressed, will permit the organization to increase revenue, avoid costs, improve service, or meet regulatory requirements.
Business Requirements Document — A Business Requirements Document is a requirements package that describes business requirements and stakeholder requirements (it documents requirements of interest to the business, rather than documenting business requirements).
Business Rule(s) — A business rule is a specific, actionable, testable directive that is under the control of the business and supports a business policy.
Capability - A function of an organization that enables it to achieve a business goal or objective.
Cardinality - The number of occurrences of one entity in a data model that are linked to a second entity. Cardinality is shown on a data model with a special notation, number (e.g., 1), or letter (e.g., M for many).
Cause and Effect Diagram — See fishbone diagram.
Change Control Board (CCB) — A small group of stakeholders who will make decisions regarding the disposition and treatment of changing requirements.
Change-driven Methodology — A methodology that focuses on rapid delivery of solution capabilities in an incremental fashion and direct involvement of stakeholders to gather feedback on the solution’s performance.
Checklist - A quality control technique. They may include a standard set of quality elements that reviewers use for requirements verification and requirements validation or be specifically developed to capture issues of concern to the project.
Class - A descriptor for a set of system objects that share the same attributes, operations, relationships, and behavior. A class represents a concept in the system under design. When used as an analysis model, a class will generally also correspond to a real-world entity.
Class Model — A type of data model that depicts information groups as classes.
Code - A system of programming statements, symbols, and rules used to represent instructions to a computer.
Commercial-off-the-Shelf Software (COTS) — Software developed and sold for a particular market.
Competitive Analysis — A structured process which captures the key characteristics of an industry to predict the long-term profitability prospects and to determine the practices of the most significant competitors.
Constraint - A constraint describes any limitations imposed on the solution that do not support the business or stakeholder needs.
Context Diagram — An analysis model that illustrates product scope by showing the system in its environment with the external entities (people and systems) that give to and receive from the system.
Cost Benefit Analysis — Analysis done to compare and quantify the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.
Customer - A stakeholder who uses products or services delivered by an organization.
Data Dictionary — An analysis model describing the data structures and attributes needed by the system.
Data Entity — A group of related information to be stored by the system. Entities can be people, roles, places, things, organizations, occurrences in time, concepts, or documents.
Data Flow Diagram (DFD) — An analysis model that illustrates processes that occur, along with the flows of data to and from those processes.
Data Model — An analysis model that depicts the logical structure of data, independent of the data design or data storage mechanisms.
Decision Analysis — An approach to decision-making that examines and models the possible consequences of different decisions. Decision analysis assists in making an optimal decision under conditions of uncertainty.
Decision Tables — An analysis model that specifies complex business rules or logic concisely in an easy-to-read tabular format, specifying all of the possible conditions and actions that need to be accounted for in business rules.
Decision Tree — An analysis model that provides a graphical alternative to decision tables by illustrating conditions and actions in sequence.
Decomposition - A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.
Defect - A deficiency in a product or service that reduces its quality or varies from a desired attribute, state, or functionality. See also requirements defect.
Deliverable - Any unique and verifiable work product or service that a party has agreed to deliver.
Design Constraints — Software requirements that limit the options available to the system designer.
Desired Outcome — The business benefits that will result from meeting the business need and the end state desired by stakeholders.
Developer — Developers are responsible for the construction of software applications. Areas of expertise include development languages, development practices and application components.
Dialog Hierarchy — An analysis model that shows user interface dialogs arranged as hierarchies.
Dialog Map — An analysis model that illustrates the architecture of the system’s user interface.
Discovery Session — See requirements workshop.
Document Analysis — Document analysis is a means to elicit requirements of an existing system by studying available documentation and identifying relevant information.
Domain - The problem area undergoing analysis.
Domain Subject Matter Expert (SME) — A person with specific expertise in an area or domain under investigation.
Elicitation - An activity within requirements development that identifies sources for requirements and then uses elicitation techniques (e.g., interviews, prototypes, facilitated workshops, documentation studies) to gather requirements from those sources.
Elicitation Workshop — See requirements workshop.
End User — A person or system that directly interacts with the solution. End users can be humans who interface with the system, or systems that send or receive data files to or from the system.
Enterprise - An organizational unit, organization, or collection of organizations that share a set of common goals and collaborate to provide specific products or services to customers.
Enterprise Architecture — Enterprise architecture is a description of an organization’s business processes, IT software and hardware, people, operations and projects, and the relationships between them.
Entity-Relationship Diagram — An entity-relationship diagram is a graphical representation of the entities relevant to a chosen problem domain, the relationships between them, and their attributes.
Evaluation - The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time, and to identify ways to improve the solution to better meet objectives. See also metric, indicator and monitoring.
Event - An event is something that occurs to which an organizational unit, system, or process must respond.
Event Response Table — An analysis model in table format that defines the events (i.e., the input stimuli that trigger the system to carry out some function) and their responses.
Evolutionary Prototype — A prototype that is continuously modified and updated in response to feedback from users.
Exploratory Prototype — A prototype developed to explore or verify requirements.
External Interfaces — Interfaces with other systems (hardware, software, and human) that a proposed system will interact with.
Feasibility Analysis — See feasibility study.
Feasibility Study — An evaluation of proposed alternatives to determine if they are technically possible within the constraints of the organization and whether they will deliver the desired benefits to the organization.
Feature - A cohesive bundle of externally visible functionality that should align with business goals and objectives. Each feature is a logically related grouping of functional requirements or non-functional requirements described in broad strokes.
Fishbone Diagram — A diagramming technique used in root cause analysis to identify underlying causes of an observed problem, and the relationships that exist between those causes.
Focus Group — A focus group is a means to elicit ideas and attitudes about a specific product, service or opportunity in an interactive group environment. The participants share their impressions, preferences and needs, guided by a moderator.
Force Field Analysis — A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces, depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.
Functional Requirement(s) — The product capabilities, or things the product must do for its users.
Gap Analysis — A comparison of the current state and desired future state of an organization in order to identify differences that need to be addressed.
Glossary - A list and definition of the business terms and concepts relevant to the solution being built or enhanced.
Goal - See business goal.
Horizontal Prototype — A prototype that shows a shallow, and possibly wide, view of the system’s functionality, but which does not generally support any actual use or interaction.
Impact Analysis — An impact analysis assesses the effects that a proposed change will have on a stakeholder or stakeholder group, project, or system.
Implementation Subject Matter Expert (SME) — A stakeholder who will be responsible for designing, developing, and implementing the change described in the requirements and have specialized knowledge regarding the construction of one or more solution components.
Included Use Cases — A use case composed of a common set of steps used by multiple use cases.
Incremental Delivery — Creating working software in multiple releases so the entire product is delivered in portions over time.
Indicator - An indicator identifies a specific numerical measurement that indicates progress toward achieving an impact, output, activity or input. See also metric.
Initiative - Any effort undertaken with a defined goal or objective.
Inspection - A formal type of peer review that utilizes a predefined and documented process, specific participant roles, and the capture of defect and process metrics. See also structured walkthrough.
Interface - A shared boundary between any two persons and/or systems through which information is communicated.
Interoperability - Ability of systems to communicate by exchanging data or services.
Interview - A systematic approach to elicit information from a person or group of people in an informal or formal setting by asking relevant questions and documenting the responses.
Iteration - A process in which a deliverable (or the solution overall) is progressively elaborated upon. Each iteration is a self-contained “mini-project” in which a set of activities are undertaken, resulting in the development of a subset of project deliverables. For each iteration, the team plans its work, does the work, and checks it for quality and completeness. (Iterations can occur within other iterations as well. For example, an iteration of requirements development would include elicitation, analysis, specification, and validation activities.)
Knowledge Area — A group of related tasks that support a key function of business analysis.
Lessons Learned Process — A process improvement technique used to learn about and improve on a process or project. A lessons learned session involves a special meeting in which the team explores what worked, what didn’t work, what could be learned from the just-completed iteration, and how to adapt processes and techniques before continuing or starting anew.
Metadata - Metadata is information that is used to understand the context and validity of information recorded in a system.
Methodology - A set of processes, rules, templates, and working methods that prescribe how business analysis, solution development and implementation is performed in a particular context.
Metric - A metric is a quantifiable level of an indicator that an organization wants to accomplish at a specific point in time.
Model(s) — A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication and understanding.
Monitoring - Monitoring is a continuous process of collecting data to determine how well a solution is implemented compared to expected results. See also metric and indicator.
Need(s) — See business need.
Non-functional Requirement(s) — The quality attributes, design and implementation constraints, and external interfaces that the product must have.
Objective - A target or metric that a person or organization seeks to meet in order to progress towards a goal.
Object Oriented Modeling — An approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one another. In some organizations, the same approach is used for business engineering to describe and package the logical components of the business.
Observation - Observation is a means to elicit requirements by conducting an assessment of the stakeholder’s work environment.
Operational Support — A stakeholder who helps to keep the solution functioning, either by providing support to end users (trainers, help desk) or by keeping the solution operational on a day-to-day basis (network and other tech support).
Operative Rule(s) — The business rules an organization chooses to enforce as a matter of policy. They are intended to guide the actions of people working within the business. They may oblige people to take certain actions, prevent people from taking actions, or prescribe the conditions under which an action may be taken.
Opportunity Analysis — The process of examining new business opportunities to improve organizational performance.
Optionality - Defining whether or not a relationship between entities in a data model is mandatory. Optionality is shown on a data model with a special notation.
Organization - An autonomous unit within an enterprise under the management of a single individual or board, with a clearly defined boundary that works towards common goals and objectives. Organizations operate on a continuous basis, as opposed to an organizational unit or project team, which may be disbanded once its objectives are achieved.
Organization Modeling — The analysis technique used to describe roles, responsibilities and reporting structures that exist within an organization.
Organizational Process Asset — All materials used by groups within an organization to define, tailor, implement, and maintain their processes.
Organizational Readiness Assessment — An assessment that describes whether stakeholders are prepared to accept the change associated with a solution and are able to use it effectively.
Organizational Unit — Any recognized association of people in the context of an organization or enterprise.
Peer Review — A validation technique in which a small group of stakeholders evaluates a portion of a work product to find errors to improve its quality.
Plan-driven Methodology — Any methodology that emphasizes planning and formal documentation of the processes used to accomplish a project and of the results of the project. Plan-driven methodologies emphasize the reduction of risk and control over outcomes over the rapid delivery of a solution.
Prioritization - The process of determining the relative importance of a set of items in order to determine the order in which they will be addressed.
Problem Statement — A brief statement or paragraph that describes the problems in the current state and clarifies what a successful solution will look like.
Process - See business process.
Process Map — A business model that shows a business process in terms of the steps and input and output flows across multiple functions, organizations, or job roles.
Process Model — A visual model or representation of the sequential flow and control logic of a set of related activities or actions.
Product - A solution or component of a solution that is the result of a project.
Product Backlog — A set of user stories, requirements or features that have been identified as candidates for potential implementation, prioritized, and estimated.
Product Scope — The features and functions that characterize a product, service or result.
Project - A temporary endeavor undertaken to create a unique product, service or result.
Project Charter — A document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities.
Project Manager — The stakeholder assigned by the performing organization to manage the work required to achieve the project objectives.
Project Scope — The work that must be performed to deliver a product, service, or result with the specified features and functions. See also scope.
Prototype - A partial or preliminary version of the system.
Quality - The degree to which a set of inherent characteristics fulfills requirements.
Quality Assurance — Activities performed to ensure that a process will deliver products that meet an appropriate level of quality.
Quality Attributes — The subset of nonfunctional requirements that describes properties of the software’s operation, development, and deployment (e.g., performance, security, usability, portability, and testability).
Questionnaire - See survey.
Regulator - A stakeholder with legal or governance authority over the solution or the process used to develop it.
Relationship - A defined association between concepts, classes or entities. Relationships are usually named and include the cardinality of the association.
Relationship Map — A business model that shows the organizational context in terms of the relationships that exist among the organization, external customers, and providers.
Repository - A real or virtual facility where all information on a specific topic is stored and is available for retrieval.
Request For Information (RFI) — A requirements document issued to solicit vendor input on a proposed process or product. An RFI is used when the issuing organization seeks to compare different alternatives or is uncertain regarding the available options
Request For Proposal (RFP) — A requirements document issued when an organization is seeking a formal proposal from vendors. An RFP typically requires that the proposals be submitted following a specific process and using sealed bids which will be evaluated against a formal evaluation methodology.
Request For Quote (RFQ) — An informal solicitation of proposals from vendors.
Requirement - A condition or capability needed by a 1. stakeholder to solve a problem or achieve an objective. A condition or 2. capability that must be met of possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents. 3. A documented representation of a condition or capability as in 1) or 2).
Requirement(s) Attribute — Metadata related to a requirement used to assist with requirements development and management.
Requirement(s) Defect — An error in requirements caused by incorrect, incomplete, missing, or conflicting requirements.
Requirements Allocation — The process of apportioning requirements to subsystems and components (i.e., people, hardware, and software).
Requirements Discovery Session — See requirements workshop.
Requirements Document — See requirements package.
Requirements Iteration — An iteration that defines requirements for a subset of the solution scope. For example, an iteration of requirements would include identifying a part of the overall product scope to focus upon, identifying requirements sources for that portion of the product, analyzing stakeholders and planning how to elicit requirements from them, conducting elicitation techniques, documenting the requirements, and validating the requirements.
Requirements Management — The activities that control requirements development, including requirements change control, requirements attributes definition, and requirements traceability.
Requirements Management Plan — A description of the requirements management process.
Requirements Management Tool — A software tool that stores requirements information in a database, captures requirements attributes and associations, and facilitates requirements reporting.
Requirements Model — A representation of requirements using text and diagrams. Requirements models can also be called user requirements models or analysis models and can supplement textual requirements specifications.
Requirements Package — A requirements package is a set of requirements grouped together in a document or presentation for communication to stakeholders.
Requirements Quality — See requirements validation and requirements verification.
Requirements Risk Mitigation Strategy — An analysis of requirements-related risks that ranks risks and identifies actions to avoid or minimize those risks.
Requirements Signoff — Formal approval of a set of requirements by a sponsor or other decision maker.
Requirements Trace Matrix — A matrix used to track requirements’ relationships. Each column in the matrix provides requirements information and associated project or software development components.
Requirements Traceability — The ability to identify and document the lineage of each requirement, including its derivation (backward traceability), its allocation (forward traceability), and its relationship to other requirements.
Requirements Validation — The work done to ensure that the stated requirements support and are aligned with the goals and objectives of the business.
Requirements Verification — The work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the design, development and implementation of the solution.
Requirements Workshop — A requirements workshop is a structured meeting in which a carefully selected group of stakeholders collaborate to define and or refine requirements under the guidance of a skilled neutral facilitator.
Retrospective — See lessons learned process.
Return on Investment — A measure of the profitability of a project or investment.
Risk — An uncertain event or condition that, if it occurs, will affect the goals or objectives of a proposed change.
Risk Mitigation Strategy — See requirements risk mitigation strategy.
Root Cause Analysis — Root cause analysis is a structured examination of an identified problem to understand the underlying causes.
Scenario - An analysis model that describes a series of actions or tasks that respond to an event. Each scenario is an instance of a use case.
Scope - The area covered by a particular activity or topic of interest. See also project scope and solution scope.
Scope Model — A model that defines the boundaries of a business domain or solution.
Secondary Actor — An actor who participates in but does not initiate a use case.
Sequence Diagram — A type of diagram that shows objects participating in interactions and the messages exchanged between them.
Service - Work carried out or on behalf of others.
Software Engineer — See developer.
Software/Systems Requirements Specification — A requirements document written primarily for Implementation SMEs describing functional and nonfunctional requirements.
Solution - A solution meets a business need by resolving a problem or allowing an organization to take advantage of an opportunity.
Solution Requirement — A characteristic of a solution that meets the business and stakeholder requirements. May be subdivided into functional and non-functional requirements.
Solution Scope — The set of capabilities a solution must deliver in order to meet the business need. See also scope.
Span of Control — Span of control is the number of employees a manger is directly (or indirectly) responsible for.
Sponsor — A stakeholder who authorizes or legitimizes the product development effort by contracting for or paying for the project.
Stakeholder — A group or person who has interests that may be affected by an initiative or influence over it.
Stakeholder Analysis - The work to identify the stakeholders who may be impacted by a proposed initiative and assess their interests and likely participation.
Stakeholder List, Roles, and Responsibility Designation — A listing of the stakeholders affected by a business need or proposed solution and a description of their participation in a project or other initiative.
Stakeholder Requirement — Stakeholder requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various categories of solution requirements.
State Diagram — An analysis model showing the life cycle of a data entity or class.
State Machine Diagram — See state diagram.
State Transition Diagram — See state diagram.
Stated Requirements — A requirement articulated by a stakeholder that has not been analyzed, verified, or validated. Stated requirements frequently reflect the desires of a stakeholder rather than the actual need.
Structural Rule — Structural rules determine when something is or is not true or when things fall into a certain category. They describe categorizations that may change over time.
Storyboard — See dialog hierarchy and dialog map.
Structured Walkthrough — A structured walkthrough is an organized peer review of a deliverable with the objective of finding errors and omissions. It is considered a form of quality assurance.
Subject Matter Expert (SME) — A stakeholder with specific expertise in an aspect of the problem domain or potential solution alternatives or components.
Supplier — A stakeholder who provides products or services to an organization.
Survey — A survey administers a set of written questions to stakeholders in order to collect responses from a large group in a relatively short period of time.
Swimlane — The horizontal or vertical section of a process model that show which activities are performed by a particular actor or role.
SWOT Analysis — SWOT is an acronym for Strengths, Weaknesses, Opportunities and Threats. It is a model used to understand influencing factors and how they may affect an initiative.
System — A collection of interrelated elements that interact to achieve an objective. System elements can include hardware, software, and people. One system can be a sub-element (or subsystem) of another system.
Technical Constraint(s) — Technical constraints are limitations on the design of a solution that derive from the technology used in its implementation. See also business constraint.
Technique — Techniques alter the way a business analysis task is performed or describe a specific form the output of a task may take.
Temporal Event — A system trigger that is initiated by time.
Tester — A stakeholder responsible for assessing the quality of, and identifying defects in, a software application.
Throw-away Prototype — A prototype used to quickly uncover and clarify interface requirements using simple tools, sometimes just paper and pencil. Usually discarded when the final system has been developed.
Timebox — A fixed period of time to accomplish a desired outcome.
Traceability — See requirements traceability.
Transition Requirement(s) — A classification of requirements that describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.
Unified Modeling Language (UML) — A non-proprietary modeling and specification language used to specify, visualize, and document deliverables for object-oriented software-intensive systems.
Use Case — An analysis model that describes the tasks that the system will perform for actors and the goals that the system achieves for those actors along the way.
Use Case Diagram — A type of diagram defined by UML that captures all actors and use cases involved with a system or product.
User — A stakeholder, person, device, or system that directly or indirectly accesses a system.
User Acceptance Test — Test cases that users employ to judge whether the delivered system is acceptable. Each acceptance test describes a set of system inputs and expected results.
User Requirement — See stakeholder requirement(s).
User Requirements Document — A requirements document written for a user audience, describing user requirements and the impact of the anticipated changes on the users.
User Story — A high-level, informal, short description of a solution capability that provides value to a stakeholder. A user story is typically one or two sentences long and provides the minimum information necessary to allow a developer to estimate the work required to implement it.
Validated Requirements — Requirements that have been demonstrated to deliver business value and to support the business goals and objectives.
Validation — The process of checking a product to ensure that it satisfies its intended use and conforms to its requirements. Validation ensures that you built the correct solution. Also see requirements validation.
Variance Analysis — Analysis of discrepancies between planned and actual performance, to determine the magnitude of those discrepancies and recommend corrective and preventative action as required.
Verification — The process of checking that a deliverable produced at a given stage of development satisfies the conditions or specifications of the previous stage. Verification ensures that you built the solution correctly. Also see requirements verification.
Verified Requirements — Requirements that have been shown to demonstrate the characteristics of requirements quality and as such are cohesive, complete, consistent, correct, feasible, modifiable, unambiguous, and testable.
Vertical Prototype — A prototype that dives into the details of the interface, functionality, or both.
Vision Statement (product vision statement) — A brief statement or paragraph that describes the why, what, and who of the desired software product from a business point of view.
Walkthrough — A type of peer review in which participants present, discuss, and step through a work product to find errors. Walkthroughs of requirements documentation are used to verify the correctness of requirements. See also structured walkthrough.
Work Breakdown Structure (WBS) — A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.
Work Product — A document or collection of notes or diagrams used by the business analyst during the requirements development process.


SWOT-анализ

SWOT Analysis

Purpose

A SWOT analysis is a valuable tool to quickly analyze various aspects of the current state of the business process undergoing change.

Description

SWOT is an acronym for Strengths, Weaknesses, Opportunities, and Threats. SWOT analysis is a framework for strategic planning, opportunity analysis, competitive analysis, business and product development.

Elements

The steps to conduct a SWOT analysis are as follows:

  • Draw a grid or matrix.
  • Describe the issue or problem under discussion at the top of the grid.
  • Conduct a brainstorming session to complete each section in the grid. Strengths and Weaknesses are factors internal to the organization, organizational unit, or solution, while Opportunities and Threats are external factors.
    • Strengths: Anything that the assessed group does well. May include experienced personnel, effective processes, IT systems, customer relationships, or any other internal factor that leads to success.
    • Weaknesses. Those things that the assessed group does poorly or not at all. Weaknesses are also internal.
    • Opportunities. External factors that the assessed group may be able to take advantage of. May include new markets, new technology, changes in the competitive marketplace, or other forces. Opportunities exist beyond the scope of control of the assessed group; the choice is whether or not to take advantage of one when it is identified.
    • Threats. External factors that can negatively affect the assessed group. They may include factors such as the entrance into the market of a new competitor, economic downturns, or other forces. Threats are also outside of the group’s control.
  • Facilitate a discussion to analyze the results. Remember that the group has identified only potential characteristics of the problem. Further analysis is needed to validate the actual characteristics, ideally confirmed with data.
  • Once the characteristics of the issue or problem have been validated, the group brainstorms potential solutions to solve the problem. A standard practice for this is to compare internal strengths and weaknesses against external opportunities and threats and try to define strategies for each cell in the matrix.

SWOT Matrix

Usage Considerations

Advantages

The SWOT analysis helps quickly analyze various aspects of the current state of the organization and its environment prior to identifying potential solution options.

Disadvantages

The SWOT analysis is a very high-level view; more detailed analysis is almost always needed.


Предисловие

IIBA ® был основан в Торонто, Канаде, в октябре 2003 года для поддержки сообщества по бизнес-анализу:
• Создание и развитие осведомленности и признания ценности и вклада Бизнес-аналитика.
• Установление свода знаний по бизнес-анализу (BABOK®).
• Обеспечение форума для обмена знаниями и вклад в профессию бизнес-анализа.
• Публичное признание и сертифицирование квалифицированных практиков через признанную на международном уровне программу сертификации.

Комитет по Своду знаний был сформирован в октябре 2004 года, чтобы определить и разработать глобальный стандарт для практики бизнес-анализа. В январе 2005 года IIBA ® выпустила версию 1.0 Руководство к Своду бизнес-анализа знаний ® (BABOK ® Guide) для обратной связи и комментариев. В этой версии включена наброски предлагаемого контента и некоторых ключевых определений. Версия 1.4 была выпущена в октябре 2005 года, с проектом содержания в некоторых областях знаний. Версия 1.6, которая включает подробную информацию о большинстве областей знаний, были опубликованы в виде проекта в июне 2006 года и обновлены, включая исправления, в октябре 2008 года.

This publication supersedes A Guide to the Business Analysis Body of Knowledge®, Version 1.6. Following the publication of version 1.6, IIBA® sought out a number of recognized experts in business analysis and related fields and solicited their feedback on the content of that edition. Their comments were used to plan the scope of this revision. IIBA® volunteers then worked to define a structure for version 2.0 and developed the revised text, which was made available to the business analysis community for review in 2008. During that exposure period, IIBA® also solicited feedback from industry experts and business analysis practitioners through a formal review process. IIBA® received thousands of comments during this process, and this document has been revised to incorporate as many of those comments as possible.

The BABOK® Guide contains a description of generally accepted practices in the field of business analysis. The content included in this release has been verified through reviews by practitioners, surveys of the business analysis community, and consultations with recognized experts in the field. The data available to IIBA® demonstrate that the tasks and techniques described in this publication are in use by a majority of business analysis practitioners. As a result, we can have confidence that the tasks and techniques described in the BABOK® Guide should be applicable in most contexts where business analysis is performed, most of the time.

The BABOK® Guide should not be construed to mandate that the practices described in this publication should be followed under all circumstances. Any set of practices must be tailored to the specific conditions under which business analysis is being performed. In addition, practices which are not generally accepted by the business analysis community at the time of publication may be equally effective, or more effective, than the practices described in the BABOK® Guide. As such practices become generally accepted, and as data is collected to verify their effectiveness, they will be incorporated into future editions of this publication. IIBA® encourages all practitioners of business analysis to be open to new approaches and new ideas, and wishes to encourage innovation in the practice of business analysis.

The goal of this revision was to:
• Complete the description of all knowledge areas.
• Simplify the structure to make it easier to understand and apply.
• Improve the consistency and quality of text and illustrations.
• Integrate the knowledge areas and eliminate areas of overlap.
• Improve consistency with other generally accepted standards relating to the practice of business analysis.
• Extend the coverage of the BABOK® Guide to describe business analysis in contexts beyond traditional approaches to custom software application development, including but not limited to agile methodologies, Business Process Management, and commercial-off-the-shelf (COTS) application assessment and implementation.
• Clarify the relationship between business analysis and other disciplines, particularly project management, testing, and usability and information architecture.
• Focus on the practice of business analysis in the context of the individual initiative, with material on strategic or enterprise-wide business analysis separated for inclusion in a future application extension.

The major changes in this release include:
• Changes throughout to address the goals described above.
• All content has been revised and edited, and much of it has been rewritten.
• Many of the tasks found in version 1.6 have been consolidated, resulting in a reduction from 77 tasks to 32.
• Tasks in the Requirements Planning and Management Knowledge Area have been reallocated to Business Analysis Planning and Monitoring and Requirements Management and Communication.
• Three other knowledge areas have been renamed to better reflect their purpose.
• Techniques apply across multiple Knowledge Areas.
• Inputs and Outputs have been defined for all tasks.

IIBA® would like to extend its thanks and the thanks of the business analysis community to all those who volunteered their time and effort to the development of this revision, as well as those who provided informal feedback to us in other ways.