А

Актив организационного процесса (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) — Техника проверки, в которую входит оценка части работы небольшой группой участников процесса для поиска ошибок и улучшения ее качества.