Перевод выполнил: Шамаев Иван (ivan.shamaev@gmail.com). Копирование материалов глоссария запрещено!

A

Acceptance criteria — Критерии приемки: Критерии, связанные с требованиями, продуктами или циклами поставки, которые должны быть выполнены для того, чтобы добиться признания заинтересованных сторон.
Actor (business analysis) — Актор (бизнес-анализ): Человек, устройство или система, которая играет определенную роль в указанном взаимодействии с решением (solution).
Adaptive approach — Адаптивный подход: Подход, при котором решение эволюционирует в циклическом процессе обучения и обнаружения, с петлями обратной связи, в которых поощряется более позднее принятие решений.
Agile Extension to the BABOK® Guide — Расширение Agile для руководства BABOK®: Стандарт по практике бизнес-анализа в контексте agile подходов. Agile расширение для руководства BABOK было опубликовано в 2013 году Международным институтом бизнес-анализа, при партнерстве с Agile Alliance.
Allocation — Аллокация (распредление): смотрите requirements allocation — Аллокация (распределение) требований.
Architecture — Архитектура: Проектирование, структура и поведение текущих и будущих состояний структуры с точки зрения ее компонентов, а также взаимодействие между этими компонентами. Смотрите также термины: Бизнес-архитектура, Архитектура предприятия и Архитектура требований.
Artifact (business analysis) — Артефакт (бизнес-анализ): Любой объект относящийся к решению, который создается в рамках работ по бизнес-анализу.
Assumption — Предположение: Это влияющий фактор, который, как полагают, является правдой, но не был подтвержден для того, чтобы быть точным, или фактор, который может быть верен в настоящее время, но не может быть правильным в будущем.

B

Behavioural business rule — Поведенческое бизнес-правило: Бизнес-правило, которое накладывает обязательства (или запрет) на поведение, действие, осуществление на практике или процедуры; бизнес-правило, целью которого заключается формирование (регулирование) ежедневной бизнес-деятельности. Также термин известен как Оперативное правило.
Benchmarking — Бенчмаркинг: сравнение решения, процесса, услуги или стоимости системы, времени, качества или других метрик с другими лидирующими организациями для того, чтобы выявить возможности для улучшения.
Body of knowledge — Свод знаний: обобщенные знания и общепринятые практики по теме.
BPM: смотрите Управление бизнес-процессами.
Brainstorming — Мозговой штурм: Командная деятельность, целью которой является стремление производить широкий или разнообразный набор вариантов посредством быстрой генерации идей без применения критики.
Business (business analysis) — Бизнес (бизнес-анализ): Смотрите Предприятие.
Business (business world) — Бизнес (деловой мир): Экономическая система, где любая коммерческая, промышленная или профессиональная деятельность осуществляется для получения прибыли.
Business analysis — Бизнес-анализ: Практика благоприятных перемен в контексте предприятия путем определения потребностей и рекомендации решений, которые обеспечивают ценность для заинтересованных сторон.
Business analysis information — Информация бизнес-анализа: Любой вид информации на любом уровне детализации, которая используется в качестве входных данных для работ по бизнес-анализу или которая используется в качестве выходных данных по завершению работ в рамках бизнес-анализа.
Business analysis package — Пакет бизнес-анализа: документ, презентация или другая коллекция текста, матриц, диаграмм и моделей, которая представляет информацию по бизнес-анализу.
Business analyst — Бизнес-аналитик: Любой человек, который выполняет бизнес-анализ, независимо от наименования должности или организационной роли. Для получения дополнительной информации смотрите раздел «Кто такой бизнес-аналитик?».
Business analysis approach — Подход бизнес-анализа: Набор процессов, правил, руководящих указаний, эвристик и мероприятий, которые используются для выполнения бизнес-анализа в конкретном контексте.
Business analysis communication plan — План коммуникации на этапе бизнес-анализа: Описание типов коммуникаций бизнес-аналитика, которыми бизнес-аналитик будет пользоваться в ходе бизнес-анализа, получателей этих сообщений, а также форма и частота сообщений.
Business analysis effort — Усилие в бизнес-анализе: Масштабы (рамки) деятельности бизнес-аналитика, которой он занимается в течение жизненного цикла инициативы.
Business analysis plan — План бизнес-анализа: Описание запланированных мероприятий, которые бизнес-аналитик будет выполнять для того, чтобы выполнить работу по бизнес-анализу, которая связана с конкретной инициативой. Смотрите также План управления требованиями.
Business architecture — Бизнес-архитектура: Дизайн, структурирование и описание поведения (переходов) текущих и будущих состояний предприятия для обеспечения общего понимания организации. Бизнес-архитектура используется для согласования стратегических целей с тактическими потребностями.
Business case — Бизнес-кейс: Обоснование курса действий, основанное на выгодах в результате использования предлагаемого решения в сравнении с затратами, усилиями и другими факторами для того, чтобы приобрести и использовать решение.
Business decision — Бизнес-решение: Решение, которое может быть разработано на основе стратегии, административного суждения, согласованного мнения и бизнес-правил, также учитывается то, что было сделано в ответ на события или в определенных точках бизнес-процесса.
Business domain — Бизнес-домен: см. домен.
Business goal — Бизнес-цель: Состояние или условие, которое организация стремится установить или поддерживать и, как правило, обычно выражено качественно, а не количественно.
Business need — Потребность бизнеса: Проблема или возможность стратегического или тактического значения, которые необходимо рассмотреть.
Business objective — Бизнес-задача: Задача, измеримый результат для того, чтобы указать была ли достигнута бизнес-цель.
Business policy — Деловая политика: недостижимая директива, которая управляет и влияет на действия предприятия.
Business problem — Бизнес-проблема: Вопрос стратегической или тактической важности, который препятствует достижению предприятием или организацией своих целей.
Business process — Бизнес-процесс: Набор мероприятий, выполняемых непрерывно, и которые вместе реагируют на события, а также преобразовывают информацию, материалы и другие ресурсы в выходной результат. Выходной результат обеспечивает ценность непосредственно для клиентов процесса. Бизнес-процесс может быть внутренним по отношению к организации или может охватывать несколько организаций.
Business process management (BPM) — Управление бизнес-процессами: Вид управленческой деятельности, который определяет как ручные и автоматизированные процессы создаются, изменяются, отменяются и регулируются.
Business process re-engineering — Реинжиниринг бизнес-процессов: Переосмысление и перепроектирование бизнес-процессов для создания улучшений показателей производительности (эффективности).
Business requirement — Бизнес-требование: Представление целей, задач и результатов, которые описывают, почему изменение было инициировано и как будет оцениваться успешность.
Business rule — Бизнес-правило: Конкретные, осуществимые, проверяемые директивы, которые находятся под контролем бизнеса и служат критерием для руководящего поведения, формирования суждения или принятия решений.

C

Capability — Потенциал (Способность): Множество видов деятельности, которое выполняет предприятие:

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

Cause-and-effect diagram — Причинно-следственная диаграмма: Смотрите Диаграмму «Рыбьей кости».
Change — Изменение: Акт преобразования в ответ на потребность.
Change agent — Представитель (агент) по изменениям: Тот, кто является катализатором изменений.
Change control — Контроль изменений: Управление изменениями в требованиях и дизайне таким образом, чтобы влияние запрашиваемых изменений были поняты и согласованы, прежде чем эти изменения будут выполнены.
Change management — Управление изменениями: Запланированные мероприятия, инструменты и методы адресованные к изменениям со стороны человека в течении изменений инициативы, в первую очередь для того, чтобы удовлетворить потребности людей, которые больше всего пострадают от изменений.
Change strategy — Стратегия изменений: План перехода от текущего состояния к будущему состоянию для того, чтобы достигнуть желаемых бизнес-задач.
Change team — Команда по изменениям: Кросс-функциональная группа лиц, которые уполномочены осуществлять изменения. Эта группа может состоять из владельцев продуктов, бизнес-аналитиков, разработчиков, менеджеров проектов, эксперта по реализации предметной области (SMEs) или любого другого человека с соответствующим набором навыков и компетенций, необходимых для осуществления изменений.
Checklist (business analysis) — Чеклист/Контрольный список: Стандартный набор элементов качества, которые рецензенты используют для верификации требований.
Collaboration — Взаимодействие: Акт (действие) двух или более людей, работающих вместе для достижения общей цели.
Commercial off-the-shelf (COTS) — Коммерческие, готовые к использованию технологии (COTS): Предварительно упакованное решение, доступное на рынке, которое решает все или большую часть общих потребностей большой группы покупателей этих решений. Коммерческие готовые решения требуют некоторой настройки для удовлетворения конкретных потребностей предприятия.
Competitive analysis — Конкурентный анализ: Структурированная оценка, которая фиксирует основные характеристики отрасли, чтобы предсказать долгосрочные перспективы прибыльности и определить практики наиболее значимых конкурентов.
Component — Компонент: Уникальный идентифицируемый элемент большого целого, который выполняет четкую функцию.
Concept model — Концептуальная модель: Модель анализа, которая развивает смысл основных понятий для проблемной области (домена), определяет их коллективную структуру и указывает на соответствующую лексику, необходимую для согласованного общения в рамках домена.
Constraint (business analysis) — Ограничение/Сдерживающий фактор: Влияющий фактор, который нельзя изменить, что накладывает пределы или ограничения на возможное решение или вариант решения.
Context — Контекст: Обстоятельства, которые влияют и обеспечивают понимание изменений.
Core concept (business analysis) — Ключевая концепция: Одна из шести идей, которые являются основополагающими в практике бизнес-анализа: Change (Изменение), Need (Потребность), Solution (Решение), Context (Контекст), Stakeholder (Заинтересованные стороны), and Value (Ценность).
Cost-benefit analysis — Анализ затрат и выгод: Анализ, который сравнивает и количественно оценивает финансовые и нефинансовые затраты на произведение изменений или реализацию решения по сравнению с приобретаемыми выгодами.
COTS: Смотрите Коммерческая, готовая к использованию технология.
Create, read, update, and delete matrix (CRUD matrix) — Матрица создания, чтения, обновления и удаления (CRUD матрица): двумерная матрица, показывающая, какие роли пользователей имеют разрешение на доступ к конкретной информационной сущности, а также на создание новых записей в этих сущностях, просмотр данных по существующим записям, обновление или модификацию данных в существующих записях, или удаление существующих записей. Тот же тип матрицы может быть использован для того, чтобы показать какие процессы, вместо пользователей, имеют права создания, чтения, обновления или удаления.
CRUD матрица: Смотрите Матрица создания, чтения, обновления и удаления.
Customer — Заказчик: Заинтересованная сторона, которая использует или может использовать продукты или услуги, произведенные предприятием, а также может иметь договорные или моральные права, которые предприятие обязано удовлетворить.

D

Decision analysis — Анализ принимаемых решений: Подход к принятию решений, который изучает и моделирует возможные последствия разных решений, а также помогает в принятии оптимального решения в условиях неопределенности.
Decomposition — Декомпозиция: Метод, который позволяет разложить проблему на составные части в целях облегчения анализа и понять эти отдельные компоненты.
Defect — Дефект: неполноценность в продукте или услуге, которая снижает их качество или меняет желаемый атрибут, состояние или функциональность.
Definitional business rule — Дефиниционное (определяющее) бизнес-правило: правило, которое указывает, что что-то обязательно верно (или неверно); Правило, которое предназначено в качестве дифиниционного критерия для понятия, знания или информации. Также известно как структурное правило.
Deliverable — Конечный результат: Любой уникальный и поддающийся проверке рабочий продукт или услуга, который одна из сторон согласилась поставить.
Design — Проектирование (Дизайн): Удобное представление решения. Для получения дополнительной информации смотрите раздел Ключевые требования (Глава 1) и Требования и проектирование (Глава 7).
Document analysis (business analysis) — Анализ документов: Анализ документации по существующей системе в целях получения требований.
Domain — Домен: Сфера знаний, которая определяет набор общих требований, терминологию и функциональность для любого ПО или
инициативы решения проблемы.
Domain subject matter expert — Эксперт по предметной области домена: Заинтересованная сторона с глубокими знаниями по теме, которая имеет отношение к бизнес-потребности или к рамкам решения (solution scope).
DSDM: Смотрите Метод разработки динамических систем.
Dynamic systems development method (DSDM) — Метод разработки динамических систем: Структура (фреймворк) выполнения проекта, которая фокусируется на фиксируемой стоимости, качестве и времени начала проекта, а в случае непредвиденных обстоятельствах управляется путем изменения особенностей для того, чтобы выполнить работы.

E

Elicitation — Выявление/сбор: Итерационная деривация (отведение) и извлечение информации из заинтересованных сторон или других источников.
End user — Конечный пользователь: Заинтересованная сторона, непосредственно взаимодействующая с решением.
Enterprise — Предприятие: Система из одной или нескольких организаций и решений, которые они используют для того, чтобы следовать набору общих целей.
Enterprise architecture — Архитектура предприятия: Описание бизнес-процессов, информационных технологий, людей, операций, информации, проектов предприятия, а также описание отношений между ними.
Enterprise readiness assessment — Оценка готовности предприятия: Оценка, которая описывает готово ли предприятие принять изменение, связанное с решением, а также — способно ли предприятие эффективно использовать решение.
Entity-relationship diagram — Диаграмма сущность-связь: Графическое представление сущностей, связанных с выбранным проблемным доменом (областью), и отношений между этими сущностями.
Estimate — Приблизительная оценка: Количественная оценка плановых результатов, потребностей в ресурсах и график, где неопределенности и неизвестности систематически учитываются при оценке.
Evaluation — Детальная оценка: Системная и объективная оценка решения для того, чтобы определить его статус и эффективность выполнения задач на длительном промежутке времени, а также идентификация путей улучшения решения, чтобы лучше подходить к выполнению задач. Смотрите также Индикаторы, Метрики, Мониторинг.
Event (business analysis) — Событие: Происшествие или инцидент, на которые должны реагировать подразделение организации, система или процесс.
Evolutionary prototype — Эволюционный прототип: прототип, который постоянно изменяется и обновляется в ответ на обратную связь от заинтересованных сторон.
Experiment — Эксперимент: Выявление/сбор данных, выполняемый в управляемом режиме для того, чтобы сделать открытие, проверить гипотезу или продемонстрировать известный факт.
External interface — Внешний интерфейс: Взаимодействие, которое находится за пределами предлагаемого решения. Это может быть другая аппаратная система (hardware system), системное программное обеспечение или взаимодействие с человеком, с которым предлагаемое решение будет в дальнейшем взаимодействовать.

F

Facilitation — Упрощение формальностей: Искусство ведения и поощрения людей посредством систематических усилий по достижению согласованных задач таким образом, чтобы повысить вовлечение, сотрудничество, производительность и синергию.
Feasibility study — Технико-экономическое обоснование (ТЭО): оценка предлагаемых альтернатив для того, чтобы определить, являются ли они в техническом, организационном и экономическом плане возможными в пределах ограничений предприятия, а также смогут ли они обеспечить желаемые выгоды для предприятия.
Feature — Особенность/характеристика: Отличительная черта решения, которая реализует набор требований и которая обеспечивает ценность для заинтересованных сторон.
Fishbone diagram — Диаграмма «Рыбьей кости»: Методика построения диаграмм, используемая в анализе первопричин для того, чтобы выявить причины, которые лежат в основе рассматриваемой проблеме, а также взаимоотношения, которые существуют между этими причинами. Также известна как Диаграмма Исикавы или причинно-следственная диаграмма.
Focus group — Фокус-группа: группа, сформированная для того, чтобы выявить идеи и взгляды о конкретном товаре, услуге или возможность в интерактивной среде группы. Участники делятся своими впечатлениями, предпочтениями и потребностями под руководством модератора.
Force field analysis — Анализ силовых полей: Графический метод для изображения сил, которые поддерживают или выступают против изменения. Включает в себя выявление сил, изображение их на противоположных сторонах линии (поддерживающие и противостоящие силы), а затем оценивание можности каждого набора сил.
Functional requirement — Функциональное требование: Способность/возможность, которую решение должно иметь в терминах поведения и информации, которой решение будет управлять.

G

GAP analysis — Анализ разрывов: Сравнение текущего состояния и желаемого будущего состояния предприятия с целью выявления различий, которые необходимо решить.
Goal — Цель: Смотрите Бизнес-цель.
Governance process (change) — Процесс управления (изменения): Процесс, с помощью которого соответствующие лица, принимающие решения, используют релевантную информацию для того, чтобы принять решение об изменении или Решении (solution), включая методы получения разрешений и приоритетов.
Guideline (business analysis) — Руководство (бизнес-анализ): Инструкция или описание того, «почему?» или «как?» осуществить задачу.

H

Horizontal prototype — Горизонтальный прототип: Прототип, который используется для исследования требований и дизайна на одном уровне с предлагаемым решением, например, такие как взгляд со стороны клиента или интерфейс другой организации.

I

Impact analysis — Анализ воздействия\влияния: Оценка эффекта предлагаемого изменения, оказываемого на заинтересованную сторону или группу заинтересованных сторон, проект или систему.
Implementation subject matter expert — Эксперт по реализации в предметной области: Заинтересованная сторона, которая имеет специальные знания относительно реализации одного или нескольких компонентов Решения.
Indicator — Индикатор: Конкретная числовая мера, которая показывает прогресс достижения влияния, результата, мероприятия или входных данных. Смотрите также Метрика.
Initiative — Инициатива: конкретный проект, программа или мероприятие, предпринимаемое для решения какой-либо бизнес-проблемы или для достижения некоторой конкретной задачи по изменениям (или нескольких задач по изменениям).
Input (business analysis) — Вход: Потребляемая или трансформируемая информация для того, чтобы получить выходной результат (выход). Вход — это информация, необходимая для того, чтобы задача была начата.
Inspection — Инспектирование/осмотр: Официальное рассмотрение рабочего продукта квалифицированными лицами, которые следуют предопределенному процессу и используют предопределенные критерии для идентификации и устранения дефектов.
Interface — Интерфейс: Общая граница между любыми двумя людьми и/или системами, через которую передается информация.
Interoperability — Взаимодействие: Способность систем взаимодействовать путем обмена данными или услугами.
Interview — Интервью: Выявление информации от человека или группы людей в неофициальной или официальной обстановке, задавая соответствующие вопросы и записывая ответы.
Ishikawa diagram — Диаграмма Исикавы: Смотрите Диаграмму «Рыбьей кости».
Iteration (business analysis) — Итерация: Один экземпляр прогрессивного цикла анализа, разработки, тестирования или исполнения.

K

Knowledge area (business analysis) — Область знаний: Область экспертизы, которая включает в себя ряд конкретных задач по бизнес-анализу.

L

Lessons learned process — Процесс извлечения уроков: Методика усовершенствования процесса, используемая для того, чтобы изучить и улучшить процесс или проект. Сессия извлечения уроков включает в себя специальное совещание, на котором команда исследует то, что работало и то, что не работало, какие уроки можно извлечь из только что завершенной итерации, а также как адаптировать процессы и методы, прежде чем продолжить или начать этам заново.
Life cycle — Жизненный цикл: Ряд изменений вопроса или объекта с самого начала до утилизации/списания.

M

Matrix — Матрица: Текстовая форма моделирования, используемая для представления информации, которая может быть представлена по категориям, в виде перекрестных ссылок, а также в табличном формате.
Metadata — Метаданные: Описание данных, которые помогут понять, как использовать эти данные, либо с точки зрения структуры и спецификации данных, либо как описание конкретного экземпляра объекта.
Methodology — Методология: Совокупность методов, приемов, процедур, рабочих концепций, а также правил, используемых для решения проблем.
Metric — Метрика: Количественный уровень индикатора (показателя), который измеряется в заданный момент времени.
Mission statement — Заявление о миссии: Официальное заявление о ценностях и целях, которые выражают центральное назначение предприятия.
Model — Модель: Представление и упрощение реальности, разработанное для того, чтобы передать информацию определенной аудитории с целью содействия анализу, общению и пониманию.
Monitoring — Мониторинг: Сбор данных на постоянной основе из Решения для того, чтобы определить насколько хорошо реализовано Решение по сравнению с ожидаемыми результатами. Смотрите также Метрика; Индикатор (Показатель).

N

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

O

Objective — Задача: Смотрите Бизнес-задача.
Observation (business analysis) — Наблюдение: Изучение и анализ одного или нескольких заинтересованных лиц в их рабочей среде с целью выявления требований.
OLAP: Смотрите Аналитическая обработка в реальном времени (Online analytical processing).
Online analytical processing (OLAP) — Аналитическая обработка в реальном времени: Подход в бизнес-аналитике (BI), который позволяет пользователям анализировать большие объемы данных с различных точек зрения.
Operational support — Операционная поддержка: Заинтересованное лицо, которое несет ответственность за повседневное управление и техническое обслуживание системы или продукта.
Operative rule — Оперативное правило: Смотрите Поведенческое бизнес-правило.
Organization — Организация: Автономная группа людей под руководством одного лица или Совета, которая работает для достижения общих целей и задач.
Organizational capability — Организационный потенциал: Функция внутри предприятия, состоящая из таких компонентов, как процессы, технологии и информация, которые используются организациями для достижения своих целей.
Organizational change management — Управление организационными изменениями: Смотрите Управление изменениями.
Organization modelling — Организационное моделирование: Метод анализа, используемый для описания ролей, обязанностей и структуры отчетности, которые существуют в рамках одного предприятия.
Organizational unit — Организационный юнит (подразделение): Любое признанное объединение людей внутри организации или предприятия.

P

Peer review — Рецензирование коллегами: Формальное или неформальное рецензирование рабочего продукта для того, чтобы выявить ошибки или возможности для его улучшения. Смотрите также Инспектирование.
Plan — План: Подробная схема осуществления или достижения чего-либо, как правило, включающая в себя набор событий, зависимостей, предполагаемой последовательности, расписание, результатов или итогов, требуемых материалов или ресурсов, а также указание каким образом должны быть вовлечены заинтересованные стороны.
Policy — Политика: Смотрите Деловая политика.
Predictive approach — Прогностический подход: Подход, при котором планирование и базовые показатели устанавливаются в начале жизненного цикла инициативы в целях максимального контроля и минимизации риска.
Prioritization — Приоритизация: Определение относительной важности набора элементов в целях определения порядка, в котором они будут решаться.
Process — Процесс: Комплекс мероприятий, направленных на достижение конкретных задач, путем приема одного или несколько определенных входов и превращение их в определенные выходы.
Process model — Модель процесса: Набор диаграмм и вспомогательной информации о процессе и факторах, которые могут влиять на процесс. Некоторые модели процессов используются для имитации производительности процесса.
Product (business analysis) — Продукт: Решение или компонент Решения, который является результатом инициативы.
Product backlog — Бэклог продукта: Набор пользовательских историй, требований или характеристик, которые были определены в качестве потенциальных «кандидатов» для реализации, приоритизированны и оценены.
Product scope — Рамки продукта: Смотрите Рамки решения (solution scope).
Product vision statement — Заявление о видении продукта: Краткое изложение или абзац, в котором описаны цели Решения и как оно поддерживает стратегию организации или предприятия.
Project — Проект: Временное предпринимаемое усилие для того, чтобы создать уникальный продукт, услугу или результат.
Project manager — Руководитель проекта: Заинтересованное лицо, которое несет ответственность за организацию работ, необходимых для поставки Решения, которое отвечает требованиям предприятия, а также за обеспечение выполнения задач проекта, балансируя проектными ограничениями, включая рамки проекта, бюджет, расписание, ресурсы, качество и риски.
Project scope — Рамки проекта: Работа, которая должна быть выполнена для того, чтобы поставить продукт, услугу или результат с конкретными особенностями и функциями.
Proof of concept — Подтверждение концепции: Модель, созданная для того, чтобы проверить дизайн Решения без моделирования внешнего вида, материалов, использующихся в работе, или без процессов и документооборота, которые используются в итоге заинтересованными сторонами.
Prototype — Прототип: Частичное или имитируемое приближение Решения с целью выявления или проверки требований с заинтересованными сторонами.

Q

Quality — Качество: Степень, в которой набор заложенных характеристик удовлетворяет потребностям.
Quality assurance — Обеспечение качества: Набор мероприятий, который осуществляется для того, чтобы процесс поставлял продукцию, отвечающую соответствующему уровню качества.
Quality attributes — Атрибуты качества: Совокупность мер, используемых для оценки общего качества системы. Смотрите также Нефункциональные требования.
Questionnaire — Анкета: Набор определенных вопросов, с выбором ответов, которые используются для сбора информации от респондентов.

R

RACI matrix — RACI матрица: Смотрите Матрица ответственных, подотчетных, консультируемых и Информируемых лиц.
Regulator — Регулятор: Заинтересованная сторона за пределами организации, которая несет ответственность за определение и исполнение стандартов.
Repository — Репозиторий/хранилище: Реальный или виртуальный объект, в котором хранится вся информация по конкретной теме, доступная для поиска.
Request for information (RFI) — Запрос информации: Формальный метод выявления предназначенный для сбора информации о возможностях поставщика или любой другой информации, связанной с возможными предстоящими закупками.
Request for proposal (RFP) — Запрос предложения: Документ по требованиям, выдаваемый, когда организация стремится получить официальное предложение от поставщиков. Запрос предложения обычно требует, чтобы предложения были представлены в соответствии с неким процессом и использовались в виде запечатанных конвертов, которые будут оцениваться в соответствии с формальной оценочной методологией.
Request for quote (RFQ) — Запрос о цене: Метод осуществления закупок путем выпрашивания цены и вариантов Решения у поставщиков.
Request for tender (RFT) — Запрос на участие в тендере: Открытое приглашение поставщикам для того, чтобы представить предложение на товары или услуги.
Requirement — Требование: Годное к использованию представление о потребности.
Requirements attribute — Атрибут требований: Характеристика или свойство требования, используемые для того, чтобы помочь в управлении требованиями.
Requirements allocation — Распределение/аллокация требований: Процесс назначения требований, которые должны быть реализованы в конкретных компонентах Решения.
Requirements architecture — Архитектура требований: Требования инициативы и взаимосвязи между этими требованиями.
Requirements artifact — Артефакт требований: Артефакт бизнес-анализа, содержащий информацию о требованиях, таких как диаграмма, матрица, документ или модель.
Requirements defect — Дефект требований: Проблема или ошибка в требовании. Дефекты могут возникать из-за плохого качества требования (смотрите Верификация требований) или потому, что требование не описывает потребность (необходимость), которая могла бы представить ценность для заинтересованных сторон (Смотрите Валидация требований).
Requirements document — Документ с требованиями: Смотрите Пакет требований.
Requirements life cycle — Жизненный цикл требований: Стадии, через которые требования развиваются от появления до их исключения.
Requirements management — Управление требованиями: Планирование, выполнение, мониторинг и контроль любых или всех работ, связанных с выявлением и взаимодействием, анализом требований и дизайном, а также управлением жизненным циклом требований.
Requirements management plan — План управления требованиями: Подмножество плана бизнес-анализа для конкретной инициативы по изменению, которое описывает конкретные инструменты, мероприятия, роли и обязанности, которые будут использоваться в ходе инициативы для управления требованиями. Смотрите План бизнес-анализа.
Requirements management tool — Инструмент управления требованиями: Специальное программное обеспечение, которое обеспечивает поддержку для любых комбинаций следующих возможностей: выявление и взаимодействие, моделирование требований и/или спецификация требований, трассировка/прослеживаемость требований, контроль версий и определение исходных данных, определение атрибутов для отслеживания и мониторинга, создание документов, а также контроль изменения требований.
Requirements model — Модель требований: Абстрактное (обычно графическое) представление некоторых аспектов текущего или будущего состояния.
Requirements package — Пакет требований: Специализированная форма пакета бизнес-анализа, прежде всего, связанная с требованиями. Пакет требований может представлять собой базовый набор требований.
Requirements traceability — Прослеживаемость (трассировка) требований: Возможность для отслеживания отношений между наборами требований и дизайном от изначальных потребностей заинтересованных сторон до фактического внедренного решения. Отслеживание/трассировка поддерживает управление изменениями, гарантируя, что источник требований или дизайна может быть идентифицирован, а также другие связанные с ними требования и дизайны, на которые возможно может повлиять известное изменение.
Requirements validation — Валидация требований: Работа, в ходе которой оцениваются требования для того, чтобы требования обеспечили получение ожидаемых выгод, а также чтобы требования находились в пределах рамок Решения.
Requirements verification — Верификация требований: Работа, в ходе которой оцениваются требования для того, чтобы они были правильно определены и находились на приемлемом уровне качества. Этот процесс гарантирует, что требования являются в достаточной степени определены и структурированы таким образом, что команда разработчиков Решения может использовать их в проектировании, разработке и реализации Решения.
Requirements workshop — Рабочий семинар по требованиям: Структурированная встреча, на которой тщательно отобранная группа заинтересованных сторон сотрудничает для того, чтобы определить и/или уточнить требования под руководством опытного нейтрального ведущего.
Residual risk — Остаточный риск: Риск, остающийся после того, как меры были предприняты или планы были приведены в действие, чтобы справиться с исходным риском.
Retrospective — Ретроспектива: Смотрите Процесс извлечения уроков.
Return on investment (ROI) (business analysis) — Окупаемость инвестиций (ROI): Мера прибыльности проекта или инвестиций.
Responsible, accountable, consulted, and informed matrix (RACI matrix) — Матрица ответственности, подотчетности, консультирования и информированности: Инструмент, используемый для определения обязанностей или ролей членов команды и их деятельности или конечных результатов, в которых они будут принимать участие, будучи ответственными (выполняет работу), подотчетными (утверждает результаты), консультирующими (обеспечение входов процесса) или информированными о завершении проблемы после того, как она будет завершена.
RFI: Смотрите Запрос информации (request for information).
RFP: Смотрите Запрос предложения (request for proposal).
RFQ: Смотрите Запрос о цене (request for quote).
RFT: Смотрите Запрос на участие в тендере (request for tender).
Risk (business analysis) — Риск: Влияние неопределенности на ценность изменения, Решение или предприятие. Смотрите также Остаточный риск.
Risk assessment — Оценка риска: Идентификация, анализ и оценка рисков.
ROI: Смотрите Окупаемость инвестиций (return on investment).
Root cause — Первопричина: Причина проблемы, которая не имеет более глубоких причин, обычно состоит из одной или нескольких возможных причин.
Root cause analysis — Анализ первопричин: Структурированная экспертиза идентифицированной проблемы для того, чтобы понять глубинные причины.

S

Scope — Рамки/границы: Границы контроля, изменений, Решения или потребностей.
Scope model — Модель границ: Модель, которая определяет границы бизнес-домена (области бизнеса) или границы Решения.
Secondary actor — Вторичный актор: Внешний актор по отношению к системе, согласно дизайну, который поддерживает выполнение варианта использования (use case).
Sequence diagram — Диаграмма последовательности: Тип диаграммы, который показывает объекты, которые участвуют во взаимодействиях, а также сообщения, которыми они обмениваются между собой.
Service (business analysis) — Услуги/сервис: Выполнение любых обязанностей или работы для заинтересованных сторон, с точки зрения заинтересованных сторон.
SIPOC: Смотрите Поставщики, Входы, Процессы, Выходы и Клиенты (suppliers, inputs, process, outputs and customers).
SME: Смотрите Эксперт предметной области (subject matter expert).
Software engineer — Инженер-программист: Смотрите Разработчик (developer).
Solution — Решение: Конкретный путь удовлетворения одной или нескольких потребностей в заданном контексте.
Solution component — Компонент Решения: Подчасть Решения, которыми могут быть люди, инфраструктура, аппаратные средства, программное обеспечение, оборудование, средства обслуживания и активы процесса или любая комбинация этих подчастей.
Solution option — Вариант/опция Решения: Один из возможных способов удовлетворения одной или нескольких потребностей в заданном контексте.
Solution requirement — Требование к Решению: Возможность или качество решения, которое отвечает требованиям заинтересованных сторон. Требования к Решению могут быть разделены на две подкатегории: функциональные требования и нефункциональные требования или требования к качеству сервиса/услуг.
Solution life cycle — Жизненный цикл Решения: Этапы, через которые совершенствуется Решение от начальной стадии до «утилизации».
Solution scope — Рамки/границы Решения: Набор возможностей решения, которые должны быть поставлены в целях удовлетворения потребностей бизнеса.
SOW: Смотрите Техническое задание (statement of work).
Sponsor — Спонсор: Заинтересованное лицо, которая несет ответственность за инициирование усилий для того, чтобы определить бизнес-потребности и разработать Решения, которое будет отвечать этим потребностям. Они санкционируют работу по выполнению и контролю бюджета, а также определяют рамки инициативы.
Stakeholder — Заинтересованная сторона: группа или лицо, имеющие отношение к изменениям, потребностям или Решению.
Stakeholder analysis — Анализ заинтересованных сторон: идентификация или анализ заинтересованных сторон, которые могут быть затронуты изменениями, или оценить их влияние, участие или потребности по всем направлениям деятельности по бизнес-анализу.
Stakeholder list — Список заинтересованных сторон: Перечень заинтересованных сторон, затрагиваемых изменением, бизнес-потребностью или предлагаемым Решением, а также описание их атрибутов и характеристик, связанных с их участием в этой инициативе.
Stakeholder proxy (business analyst) — Доверенное лицо заинтересованных сторон: Роль бизнес-аналитика, которую он на себя принимает, когда представляет интересы по потребностям заинтересованных сторон или группе заинтересованных сторон.
Stakeholder requirement — Требования заинтересованных сторон: описание потребностей конкретной заинтересованной стороны или класса заинтересованных сторон, которые должны быть выполнены для достижения бизнес-требований. Они могут служить в качестве моста между бизнес-требованиями и различными категориями требований к Решению.
State diagram — Диаграмма состояний: Модель анализа, которая показывает жизненный цикл сущности данных или класса.
Stated requirement — Заявленное требование: Требование, сформулированное заинтересованной стороной, которое не было проанализировано, верифицированно или валидировано. Заявленные требования часто отражают желания заинтересованных сторон, а не фактические потребности.
Statement of work (SOW) — Техническое задание: Письменное описание услуг или задач, которые должны быть выполнены.
Strategy — Стратегия: Описание выбранного подхода для применения возможностей предприятия в целях достижения набора желаемых целей или задач.
Strengths, weaknesses, opportunities, and threats analysis (SWOT) — Анализ сильных и слабых сторон, возможностей и угроз: Модель анализа, которая используется для того, чтобы понять влияющие факторы и как они могут повлиять на инициативу. Также известен как SWOT-анализ.
Structural rule — Структурное правило: Смотрите Определяющее бизнес-правило (definitional business rule).
Subject matter expert (SME) — Предметный эксперт: Смотрите Эксперт предметной области/домена (domain subject matter expert); Предметный эксперт по реализации (implementation subject matter expert).
Supplier — Поставщик: Заинтересованная сторона за пределами границ данной организации или организационного подразделения, которая поставляет товары или услуги для организации и может иметь договорные или неимущественные права и обязанности, которые должны быть рассмотрены.
Suppliers, inputs, process, outputs, and customers (SIPOC) — Поставщики, Входы, Процессы, Выходы и Клиенты: Инструмент, используемый для описания соответствующих высокоуровневых элементов процесса. Может быть использован в сочетании с мэппинга процесса (process mapping) и инструментов «входы и выходы границ (in/out of scope)» для того, чтобы обеспечить дополнительные детали.
Survey — Опрос: Сбор и измерение мнений и опыта группы людей с помощью серии вопросов.
Swimlane — Дорожки: Горизонтальные или вертикальные сечения диаграммы процессов, которые показывают какие виды деятельности будут осуществляться определенным актором или ролью.
SWOT analysis — SWOT анализ: Смотрите Анализ сильных и слабых сторон, возможностей и угроз.
System — Система: Набор взаимозависимых компонентов, которые взаимодействуют различными способами для того, чтобы произвести ряд желаемых результатов.

T

Task (business analysis) — Задача: Дискретная часть работы, которая может быть выполнена формально или неформально как часть бизнес-анализа.
Technique — Техника/методика: Манера, способ или стиль осуществления задачи по бизнес-анализу или для формирования ее результатов.
Temporal event — Временное событие: Событие, основанное на времени, которое может инициировать начало процесса, оценку бизнес-правила или
какие-либо другие реакции.
Tester — Тестировщик: Лицо, ответственное за определение способа, с помощью которого можно убедиться, что Решение соответствует требованиям, определенные аналитиком, а также осуществить процесс верификации.
Throw-away prototype — Одноразовый прототип: Прототип, используемый для быстрого выявления и уточнения требований или дизайна с помощью простых инструментов, иногда с помощью только бумаги и карандаша. Он предназначен для выброса, когда конечная система будет разработана.
Time-box — Временной ящик: Согласованный период времени, в котором деятельность осуществляется или определяется исходя из конечного результата, который должен быть произведен.
Traceability — Прослеживаемость/Трассировка: Смотрите Прослеживаемость требований (requirements traceability).
Transition requirement — Переходное требование: Требование, которое описывает возможности, которые должно иметь Решение, и условия, которым должно удовлетворять Решение для того, чтобы облегчить переход от текущего состояния в будущее состояние, но которые не нужны сразу после завершения изменения. Переходные требования отличаются от других типов требований, потому что они носят временный характер.

U

UAT: Смотрите Пользовательское приемочное тестирование (user acceptance test).
UML: Смотрите Унифицированный язык моделирования (unified modelling language).
Unified modelling language — Унифицированный язык моделирования: Нотация, определенная Object Management Group для описания структуры программного приложения, поведения и архитектуры. UML может также использоваться для описания бизнес-процессов и структуры данных. Наиболее распространенные диаграммы UML, используемые бизнес-аналитиками — это диаграммы use case (варианты использования), activity diagrams (диаграммы деятельности), state machine diagrams — диаграммы состояний машины (также известные как диаграммы состояний), и class diagrams (диаграммы классов).
Use case — Вариант использования: Описание наблюдаемого взаимодействия между актором (или акторами) и Решением, которое возникает, когда актор использует систему для достижения конкретной цели.
Use case diagram — Диаграмма вариантов использования: Тип диаграммы, определенный UML, которая охватывает всех акторов и все варианты использования, которые связаны с системой или продуктом.
User — Пользователь: Смотрите Конечный пользователь (end user).
User acceptance test (UAT) — Пользовательское приемочное тестирование: Оценка, соответствует ли поставляемое решение потребностям группы заинтересованных лиц, которая будет использовать решение. Оценка сверяет определенные приемочные критерии.
User requirement — Пользовательское требование: Смотрите Требование заинтересованных сторон (stakeholder requirement).
User story — Пользовательская история: Маленькое, краткое изложение функциональности или качества, которые необходимы, чтобы обеспечить ценность для конкретной заинтересованной стороны.

V

Validation (business analysis) — Валидация: Процесс проверки того, что поставляемый результат пригоден для использования по назначению. Смотрите также Валидация требований ( requirements validation).
Validated requirement — Валидация требований: Требование, которое было рассмотрено и определено для оказания содействия в осуществлении ожидаемых выгод и укладывается в рамки Решения.
Value (business analysis) — Ценность: Ценность, важность или полезность чего-либо для одной из заинтересованной стороны в заданном контексте.
Value stream mapping — Картирование потока создания ценности: Полное представление, основанное на фактах, на временной шкале потока деятельности, необходимых для поставки продукта или услуги.
Verification (business analysis) — Верификация: Процесс определения того, что поставляемый результат или артифакт соответствует приемлемому уровню качества. Смотрите также Верификация требований (requirements verification).
Verified requirement — Верифицированное/проверенное требование: Требование, которое было рассмотрено и правильно определено, которое придерживается стандартов или руководящих принципов, а также находится на приемлемом уровне детализации.
Vertical prototype — Вертикальный прототип: Прототип, который используется для того, чтобы детально раскрыть требования и дизайн в предалагаемом Решении, посредством многократных слоев Решения, которые не легко понять или которые не лежат на поверхности. Вертикальный прототип может включать в себя взаимодействие между несколькими компонентами Решения.
Viewpoint — Точка зрения: Набор соглашений, которые определяют, как требования будут представлены, как эти представления будут организованы и как они будут связаны.
VSM: Смотрите Картирование потока создания ценности (value stream mapping).

W

Walkthrough — Сквозной контроль: Рассмотрение, в котором участники проходят через артефакт или набор артефактов с целью проверки требований или дизайна, а также определяют ошибки требований или дизайна, несоответствия, упущения, неточности или конфликты.
WBS: Смотрите Иерархическая структура работ (work breakdown structure).
Work breakdown structure (WBS) — Иерархическая структура работ: Ориентированная на конечный результат иерархическая декомпозиция работ, которые должны быть выполнены для достижения задач и создания требуемых результатов. Иерархическая структура работ организует и определяет итоговые рамки (границы) проекта.
Work product (business analysis) — Рабочий продукт: Документ или коллекция примечаний или диаграмм, которые используются бизнес-аналитиком во время процесса разработки требований.
Workshop — Семинар/рабочий семинар: Управляемое и сфокусированное событие с участием заинтересованных сторон в целях достижения определенной цели.

Перевод выполнил: Шамаев Иван (ivan.shamaev@gmail.com). Копирование материалов глоссария запрещено!