Словарь BABOK
| Термин | Перевод | Определение |
| Activity Diagram | Диаграмма активности | Модель, которая иллюстрирует поток процессов и/или набор use cases показывающих длительность каждой активности вместе с информационными потоками и параллельными (пересекающимися) активностями. Шаги процессов могут быть наложены на горизонтальные "водные дорожки", отображающие активности ролей, которые выполняются по шагам |
| Activity | Активность | Блок работ, выполненный как часть инициативы (инициации) или процесса |
| Actor(s) | Эктор(ы) | Роли (Работники, процессы, подсистемы, системы) взаимодействующие с системой |
| Allocation | Назначение | Смотри requirements allocation (требования к распределению) |
| Analyst | Аналитик | Общее название для роли ответственной за развитие и управление требованиями. Включает в себя другие названия - бизнес аналитик, бизнес интегратор, инженер по требованиям и системный аналитик |
| Association | Ассоциация | Связь между двумя элементами или объектами на диаграмме |
| Assumption | Предположение | Предположения - это влияющие факторы, которые считаются верными, но являются не до конца подтвержденными для того, чтобы быть верными |
| Attribute | Атрибут | Элемент, со специфическим типом данных, который описывает ассоциацию концептуально или в виде сущности |
| Baseline | Бэйслайн | Единовременная точка зрения на требования, которая рассматривает и согласовывает их в качестве базового для будущей работы |
| Benchmarking | Сравнительный анализ | Сравнение процессной или системной стоимости, времени, качества или иной метрики |
| Black Box Tests | Тест черного ящика | Тесты, которые написаны без рассмотрения того, как реализовано программное обеспечение. Эти тесты демонстрируют только то, какими должны быть входные и выходные данные |
| Brainstorming | Мозговой штурм | Мозговой штурм - это командная активность, с помощью которой достигается «широкий» и «глубокий» набор опций, благодаря быстрой генерации идей, которые должны быть не критикуемы в процессе их генерации |
| Business Analysis | Бизнес анализ | Бизнес анализ - это набор задач и техник, используемых в работе с заинтересованными лицами для однозначного понятия структуры, политики и действий в организации. Так же рекомендует решения для достижения её целей |
| Business Analysis Approach | Подход бизнес анализа | Набор процессов, шаблонов и действий, которые могут быть использованы для того, чтобы достичь целей бизнес анализа в определенных контекстах |
| Business Analysis Communication Plan | План коммуникаций бизнес анализа | Описание видов коммуникаций, которые бизнес аналитик будет использовать в процессе бизнес анализа, ответные участники этих коммуникаций и форма, в которой коммуникации должны происходить |
| Business Analysis Plan | План бизнес анализа | Описание запланированных деятельностей, которые бизнес - аналитик будет выполнять в процессе выполнения работы по бизнес анализу, включенной в определенную инициативу |
| Business Analyst | Бизнес аналитик | Специалист, практикующий бизнес анализ |
| Business Architecture | Бизнес архитектура | Составная часть общей архитектуры предприятия, которая определяет актуальную организацию и её будущее состояние, включая стратегию, цели и задачи, внутреннюю среду процесса или функционального взгляда на него, внешнюю среду, в которой работает бизнес, заинтересованных лиц, на которых оказывает влияние организационная деятельность |
| Business Case | Бизнес условия | Оценки стоимости и выгод, связанных с предлагаемой инициативой |
| Business Constrain(s) | Бизнес ограничение(я) | Бизнес ограничения - это ограничения, возложенные на решения, принимаемые организацией, которая нуждается в решении. Бизнес ограничения описывают ограничения на доступные решения, или на аспект актуального состояния, который не может быть изменен с помощью развертывания нового решения. |
| Business Domain | Бизнес домен | Проблемная область, подвергающаяся анализу |
| Business Domain Model | Модель бизнес домена | Концептуальный взгляд на весь или часть, процесса промышленного фокусирования на продукте, результатах или событиях, которые важны для миссии организации. Модель домена полезна для валидации рамок разработанного решения с бизнес и техническими стэйкхолдерами |
| Business Event | Бизнес событие | Системный триггер, инициируемый сотрудниками |
| Business Goal | Бизнес цель | Состояния или условия при которых бизнес должен удовлетворять достижению своего видения |
| Business Need(s) | Бизнес потребность(и) | Тип высокоуровневых бизнес - требований, которые определяют цели бизнеса, или влияние, которое решение должно иметь на своё окружение |
| Business Policy | Бизнес политика | Бизнес-политика - это не применимая на практике инструкция (теоретизировании документ), которая поддерживает бизнес цель |
| Business Process | Бизнес процесс | Набор определенных, для конкретного случая, или упорядоченных совместных активностей, повторно исполняемых, конкретной организацией. Процессы вызваны событиями и могут иметь несколько возможных результатов. Успешный результат процесса будет приносить ценность одному или нескольким стэйкхолдерам |
| Business Requirement | Бизнес требования | Высокоуровневое бизнес объяснение, которое, в случае когда оно разрешено, позволит организации увеличить доход, снизить затраты, улучшить сервис, или выполнить нормативные требования |
| Business Requirements Document | Документ бизнес требований | Документ бизнес требований - это "пакет" требований, который описывает бизнес требования и требования заинтересованных лиц (этот документ интересен для бизнеса больше чем процесс документации бизнес требований) |
| Business Rule(s) | Бизнес правило(а) | Бизнес правило - это определенная, применимая, проверяемая директива, которая находиться под контролем бизнеса и поддерживается бизнес политикой |
| Capability | Способность (Возможность) | Функция организации, которая позволяет достичь ей бизнес цели или задачи |
| Cardinality | Количество элементов | Число возникновения одной сущности в модели данных, которые связаны с другой сущностью. Количество элементов показывается на модели данных с помощью специальной нотации: номер (например, 1) или буква (например, M для значения «много») |
| Cause and Effect Diagram | Диаграмма причины и следствия | Смотри "диаграмма на рыбных костях" |
| Change Control Board (CCB) | Совет контроля за изменениями | Небольшая группа стейкхолдеров, которые будут принимать решения, рассматривать расположения изменений и их отношение к изменению требований |
| Change-driven Methodology | Методология управления изменениями | Методология, которая фокусируется на быстром предоставлении возможностей, за счет принятых решений, а также на непосредственное вовлечение заинтересованных лиц для сбора ответной информации о результатах выполненного решения |
| Checklist | Контрольный список | Техника контроля качества. Она может включать стандартный набор элементов качества, которые рецензенты используют для верификации и валидации требований или специально разрабатываются для фиксирования проблем проекта |
| Class | Класс | Описатель набора системных объектов, которые совместно используются одинаковыми атрибутами, операциями, отношениями и поведением. Класс представляет концепцию разрабатываемой системы. Когда его используют в модели анализа, класс, в общем, соответствует объекту реального мира |
| Class Model | Модель класса | Тип модели данных, который отображает информацию о группе в виде классов |
| Code | Код | Система, состоящая из программных операторов, символов и правил, используемых для представления инструкций компьютеру |
| Commercial-off-the Shelf Software (COTS) | Заказное коммерческое программное обеспечение | Программное обеспечение, разрабатываемое и продаваемое в расчете на определенный сегмент рынка |
| Competitive Analysis | Сравнительный анализ | Структурированный процесс, который отображает ключевые характеристики отрасли, с целью предсказания долгосрочных перспектив, получения прибыли и определяет методы наиболее значимых конкурентов |
| Constraint | Ограничение | Ограничение описывает любые ограничения, накладываемые на решение, которое не поддерживает потребности заинтересованного лица или бизнеса |
| Context Diagram | Контекстная диаграмма | Аналитическая модель, которая демонстрирует рамки продукта, показывая систему в её окружении с внешними сущностями (люди или системы), которые отдают или получают что-то от системы |
| Cost Benefit Analysis | Анализ рентабельности | Анализ, выполненный для сравнения и определения финансовых и не финансовых затрат на осуществление изменений или реализацию (внедрение) решения, в сравнении с достигнутой выгодой |
| Customer | Заказчик | Заинтересованное лицо, использующее продукт или сервис, поставляемые организацией исполнителем |
| Data Dictionary | Словарь данных | Аналитическая модель, описывающая структуру данных и атрибуты, необходимые системе |
| Data Entity | Сущности данных | Группа связанной информации, которая должна быть сохранена в системе. Сущностями могут быть люди, роли, места, вещи, организации, происшествия во времени, понятия или документы |
| Data Flow Diagram (DFD) | Диаграмма потока данных | Аналитическая модель, которая отображает процессы в виде событий наряду с потоками данных входящих и выходящих из этих процессов |
| Data Model | Модель данных | Аналитическая модель, изображающая логическую структуру данных, независимую от физической структуры данных или механизмов хранения данных |
| Decision Analysis | Анализ решения | Подход для принятия решений, исследующий и моделирующий возможные последствия различных решений. Анализ решений способствует принятию оптимального решения в условиях неопределенности |
| Decision Tables | Таблица решений | Аналитическая модель, которая в удобной для восприятия форме, изображает комплексные бизнес правила или краткую логику, описывающая все возможные условия и действия, которые должны быть учтены в рамках бизнес-правил |
| Decision Tree | Дерево решений | Аналитическая модель, которая содержит графическую альтернативу таблице решений, описывающая последовательные условия и действия |
| Decomposition | Декомпозиция | Техника, которая подразделяет проблему на компоненты в определенном порядке для облегчения анализа и понимания этих компонентов |
| Defect | Дефект | Недостаток в продукте или услуги, который приводит к снижению его качества или к отклонению от желаемого значения атрибута, состояния или функциональности. |
| Deliverable | Поставка (Поставляемый продукт) | Любой уникальный и верифицируемый рабочий продукт или сервис, который контрагент согласен поставлять |
| Design Constraints | Системное ограничение | Требования к программному обеспечению, которые накладывают ограничения на доступную опциональность системы |
| Desired Outcome | Желаемый результат | Бизнес выгода, которая будет результатом от сопоставления бизнес-потребностей и конечного состояния, ожидаемого заинтересованными лицами |
| Developer | Разработчик | Разработчики - это ответственные за построение программных приложений. Области их экспертизы включают языки программирования, практику разработки и применение компонентов |
| Dialog hierarchy | Иерархия диалога | Аналитическая модель, которая демонстрирует пользовательский диалоговый интерфейс в качестве упорядоченной иерархии |
| Dialog Map | Карта диалога | Аналитическая модель, иллюстрирующая архитектуру пользовательского интерфейса системы |
| Discovery Session | Сессия по выявлению | Смотри требования воркшопа |
| Document Analysis | Анализ документа | Анализ документов - это выбор требований к существующей системе, путем изучения доступной документации и идентификации связанной информации |
| Domain | Область | Проблемная область, подвергающаяся анализу |
| Domain Subject Matter Expert (SME) | Субъект экспертизы области | Личность с специальными знаниями в исследуемой области или домене |
| Elicitation | Извлечение (выявление) | Деятельность над требованиями к процессу разработки, которые идентифицируют источники требований и затем применяют техники извлечения (например: интервью, прототипы, организованные семинары, изучение документации) к сбору требований |
| Elicitation Workshop | Семинар по извлечению требований | Смотри требования воркшопа |
| End User | Конечный пользователь | Персона или система, которая непосредственно взаимодействует с решением. Конечными пользователями могут быть люди, которые взаимодействуют с системой, или системы, которые отправляют или получают файлы с данными от других систем |
| Enterprise | Предприятие | Организационная единица, организация или совокупность организаций, которые разделяют набор общих целей и совместно разрабатывают определенные продукты или сервисы для покупателей |
| Enterprise Architecture | Архитектура предприятия | Архитектура предприятия - это описание организационных бизнес-процессов, ИТ обеспечения и аппаратных продуктов, персонала, операций и проектов, и связи между ними |
| Entity-Relationship Diagram | Диаграмма "сущность-связь" | Диаграмма "сущность-связь" - это графическое представление сущностей, связанных с выбранной предметной областью, отношения между ними и их атрибуты |
| Evaluation | Оценка | Систематическая и объективная оценка решения для определения его статуса и эффективности в достижении задач с течением времени, и идентификация путей улучшения решения после того, как задачи достигнуты. См. также метрики, индикаторы и мониторинг |
| Event | Событие | Событие – это что-то, что происходит, на организационной единице, системе или процессе, которые должны быть ответственны за определенные действия |
| Event Response Table | Таблица откликов на события | Аналитическая модель в формате таблицы, которая определяет события (т.е. входные стимулы, которые являются триггерами для выполнения системой некоторых функций) и их последствия |
| Evolutionary Prototype | Эволюционный прототип | Прототип, который непрерывно модифицируется и обновляется в ответ на обратную связь от пользователя |
| Exploratory Prototype | Исследовательский прототип | Прототип, разрабатываемый для исследования или верификации требований |
| External Interfaces | Внешние интерфейсы | Интерфейсы к другим системам (техническим, программным и социальным), с которыми предполагаемая система будет взаимодействовать. |
| Feasibility Analysis | Анализ осуществимости | Смотри исследование осуществимости |
| Feasibility Study | Технико-экономическое обоснование (Исследование осуществимости) | Оценка предлагаемых альтернатив для определения их технической осуществимости, с условием ограничений организации, и, каким образом, они будут предоставлять желаемые выгоды для этой организации |
| Feature | Свойство | Связанная между собой группа внешне явной функциональности, которую следует согласовать с бизнес-целями и задачами. Каждое свойство представляет собой логически взаимосвязанную группу, описанных в общих чертах, функциональных и нефункциональных требований |
| Fishbone Diagram | Диаграмма на рыбьих костях [Диаграмма Ишикавы] | Техника изображения, используемая в причинно-следственном анализе для идентификации скрытых причин рассматриваемой проблемы и связей, существующих между этими причинами |
| Focus Group | Фокус-группа | Фокус-группа представляет собой средство выявления идей и отношений о определенном продукте, услуге или возможности во взаимодействующей групповой среде. Участники делятся своими впечатлениями, предпочтениями и пожеланиями под наставничеством модератора |
| Force Field Analysis | Анализ силового поля | Графический метод для изображения сил, которые поддерживают и противодействуют изменениям. Включает в себя идентификацию сил, изображение их на противоположных сторонах линии (поддерживающие и противодействующие силы) и затем оценивание мощности каждого набора сил |
| Functional Requirement (s) | Функциональное требование (я) | Возможность продукта или то, что продукт должен делать для своих пользователей |
| Gap Analysis | Анализ разрывов | Сравнение текущего состояния и желаемого будущего состояния организации, с целью определения различий, которые должны быть устранены |
| Glossary | Словарь | Список и определения бизнес-терминов и понятий, имеющих связи с разрабатываемым решением или решением, у которого улучшают его качество |
| Goal | Цель | Смотри бизнес цель |
| Horizontal Prototype | Горизонтальный прототип | Прототип, который показывает поверхностный, и как можно более общий, вид функциональности системы, но при этом в общем еще не поддерживаемой никакими актуально используемыми взаимодействиями |
| Impact Analysis | Анализ воздействия | Анализ воздействия оценивает эффекты, которые предполагаются после того, как будут осуществлены изменения, влияющие на группу заинтересованных лиц, проект или систему |
| Implementation Subject Matter Expert (SME) | Эксперт в реализация предметной области | Заинтересованные лица, которые будут ответственны за проектирование, разработку и реализацию изменений, описанных в требованиях и имеющие специальные знания, для рассмотрения одного или более вариантов создания решения |
| Included Use Cases | Включенные варианты использования | Варианты использования, состоящие из общего набора шагов, используемых в нескольких вариантах использования |
| Incremental Delivery | Инкрементная поставка | Создание работающего программного обеспечения в множественных выпусках, таким образом, что весь продукт поставлялся по частям, в течение времени |
| Indicator | Индикатор | Индикатор идентифицирует конкретное числовое измерение, которое обозначает, прогресс в достижении воздействия, выхода, активности или входа. |
| Initiative | Инициатива | Любые предпринятые усилия по определению цели или задач |
| Inspection | Инспекция | Формальный тип экспертной оценки, которая использует предопределенный и задокументированный процесс, который определяет участвующие роли и при этом выявляет дефекты и процессные метрики. |
| Interface | Интерфейс | Распределенная граница между любыми двумя лицами и / или системой, через которую передается информация |
| Interoperability | Взаимодействие | Способность систем к взаимодействию с помощью обмена данными или сервисов |
| Interview | Интервью | Системный подход к извлечению информации от человека или группы людей в неформальной или формальной обстановке, задавая соответствующие вопросы и документируя ответы |
| Iteration | Итерация | Процесс, в котором прогрессирующе разрабатываются полные решения. Каждая итерация является самодостаточным «мини-проектом», в котором предпринят набор деятельностей, результатом которых является разработанное подмножество результирующих проектов. Для каждой итерации, проектная команда составляет план работ, выполняет и проверяет её качество и законченность. Одни итерации могут быть успешно выполнены в составе других итераций. К примеру, итерации по разработке требований могут включать выбор, анализ, определение и спецификацию деятельностей |
| Knowledge Area | Область знания | Группа связанных задач, которые поддерживают ключевую функциональность бизнес-анализа |
| Lessons Learned Process | Процесс извлечения уроков | Процесс улучшения методики обучения, используемый с целью улучшения процесса или проекта. Сессия по извлечению уроков, включает в себя специальное совещание, в котором команда исследует то, что было сделано, что не было сделано, что могло бы быть сделано в только что завершенной итерации и как адаптировать процесс и методику, перед тем как продолжать или начинать процесс снова |
| Metadata | Метаданные | Данные, которые используются для понимания контекста и оценки достоверности информации, хранящейся в системе |
| Methodology | Методология | Набор процессов, правил, шаблонов и рабочих методов, которые предписывают, каким образом при помощи бизнес анализа будет выполняться разработка и развертывание решения, применительно к конкретной ситуации |
| Metric | Показатель | Показатель – это измеримое значение идентификатора, которое организация стремится достичь к определенному моменту времени |
| Model (s) | Модель (и) | Упрощенное представление реальности, разработанное с целью донести информацию до определенной аудитории для обеспечения анализа, взаимодействия и понимания |
| Monitoring | Мониторинг | Мониторинг – это непрерывный процесс сбора данных с целью выявления, насколько внедряемое решение соответствует ожидаемым результатам. |
| Need (s) | Потребность (и) | Смотри бизнес потребности |
| Non-functional Requirement (s) | Нефункциональное требование (я) | Атрибуты качества, ограничения дизайна и развертывания, внешние интерфейсы, которые продукт должен иметь |
| Objective | Цель, объект | Результаты или показатели, к которым стремится предприятие |
| Object Oriented Modeling | Объектно-ориентированное моделирование | Подход к инженерии ПО, который включает в себя компоненты, содержащие наборы (группы) данных и функций, наследующие поведение и характеристики других компонентов. Рассматриваемые компоненты взаимодействуют друг с другом при помощи сообщений. В некоторых организациях такой подход используется для бизнес-инженерии, для описания и формирования логических компонентов бизнеса |
| Observation | Наблюдение | Наблюдение – это сбор требований на примере изучения рассматриваемых процессов при работе с ними заинтересованных, в результатах их выполнения, лиц |
| Operational Support | Поддержка операционной деятельности | Заинтересованное лицо, которое помогает поддерживать функционирование решения, также обеспечивая поддержку конечным пользователям или обеспечивая базовое каждодневное функционирование решения (новостная и другая техническая поддержка) |
| Operative Rule(s) | Правило(а) операционной деятельности | Бизнес-правила, которые выбирает организация для обеспечения в виде сущности своей политики. Они предназначаются для руководства действиями сотрудников, которые задействованы в бизнесе. Они могут обязывать работников выполнять определенные действия, удерживать сотрудников от совершения действий, или устанавливать условия, при которых действие может быть выполнено |
| Opportunity Analysis | Анализ возможностей | Процесс рассмотрения новых бизнес-возможностей с целью улучшения организационной деятельности |
| Optionality | Опциональность | Определение того, является ли или нет отношение между сущностями в модели данных обязательным. Она представляется на модели данных с помощью специальной нотации |
| Organization | Организация | Автономная единица в пределах одного предприятия под управлением одного человека или совета, с четко определенными границами, которая работает для достижения общих целей и задач. Организация управляется на непрерывной основе, в качестве противоположности можно представить организационную единицу или проектную команду, которые могут быть расформированы при достижении заданных целей |
| Organization Modeling | Организационное моделирование | Техника анализа, описывающая роли, обязанности и подотчетные структуры, которые существуют в рамках организации. |
| Organizational Process Asset | Активы организационного процесса | Все материалы, используемые группами организации для определения, адаптации, внедрения и поддержания их процессов |
| Organizational Readiness Assessment | Организационная оценка готовности | Оценка, которая определяет, готовы ли заинтересованные лица к принятию изменения связанному с текущим решением, и могут ли использовать его эффективно |
| Organizational Unit | Организационная единица | Какой-либо выделенный союз работников в контексте организации или предприятия |
| Peer Review | Экспертная оценка | Техника валидации, которая применяется в малых группах заинтересованных лиц для оценивания части рабочего продукта, для того чтобы обнаружить неточности, с целью улучшения его качества |
| Plan-driven Methodology | Управляемая планом методология | Любая методология, которая подчеркивает значение планирования и формального документирования процессов, используемых для достижения целей и результатов проекта |
| Prioritization | Приоритезация | Процесс определения относительной важности набора элементов для установления порядка, в котором эти элементы будут находиться |
| Problem Statement | Описание задачи | Ограниченное описание или изложение, описывающее проблемы в определенном состоянии и разъяснение того, как будет выглядеть успешное решение |
| Process | Процесс | Смотри бизнес процесс |
| Process Map | Карта процесса | Бизнес модель, которая демонстрирует бизнес процесс в терминах, определяющих шаги, входные и выходные потоки, перекрестную мультифункциональность организации или рабочие роли |
| Process Model | Модель процесса | Визуальная модель или представление последовательного потока и логического контроля, набора взаимосвязанных активностей или действий |
| Product | Продукт | Решение или компонент решения, являющееся результатом проекта |
| Product Backlog | Незавершенный список требований по продукту | Набор пользовательских историй, требований или свойств, которые были определены в качестве кандидатов для возможного выполнения, приоритезации и оценки |
| Product Scope | Рамки продукта | Свойства и функциональность, которые характеризуют продукт, услугу или результат |
| Project | Проект | Предпринятая деятельность, ограниченная временем, по созданию уникального продукта, сервиса или какого-либо иного результата |
| Project Charter | Устав проекта | Документ, изданный инициатором проекта или спонсором, который формально разрешает существование проекта и предоставляет руководителю проекта полномочия по использованию организационных ресурсов для проектной активности |
| Project Manager | Руководитель проекта | Заинтересованное лицо, назначенное исполняющей организацией управлять работой, требующейся для решения проектных задач |
| Project Scope | Рамки проекта | Работа, которая должна быть выполнена для предоставления законченного продукта, сервиса или результат с определенными свойствами и функциями. Также смотри рамки |
| Prototype | Прототип | Часть или предварительная версия системы |
| Quality | Качество | Уровень, при котором набор неотъемлемых характеристик соответствует заявленным требованиям |
| Quality Assurance | Контроль качества | Деятельность, выполнение которой обеспечивает то, что процесс будет поставлять продукты, которые удовлетворяют заданному уровню качества |
| Quality Attributes | Атрибуты качества | Подмножество нефункциональных требований, которое описывает свойства операций по созданию программного обеспечения, его разработки и развертыванию |
| Questionnaire | Опросник | Смотри обследование |
| Regulator | Регулятор | Заинтересованное лицо, обладающее законными или властными полномочиями по управлению процессом развития решения |
| Relationship | Отношение | Ассоциация, определенная между понятиями, классами или сущностями. Отношения обычно носят названия и включают в себя элементы ассоциации |
| Relationship Map | Карта отношений | Модель бизнеса, которая демонстрирует организационное окружение в терминах отношения, которое определяет существование организации в среде внешних покупателей и поставщиков |
| Repository | Хранилище | Реальное или виртуальное средство, в котором хранится вся информация на определенные темы. В нём она может быть восстановлена в любой момент времени |
| Request For Information (RFI) | Информационный запрос | Документ требований, оформляемый для запроса информации от потенциального поставщика, предполагаемого процесса или продукта. Этот документ нужен для сравнения или оценивания нескольких альтернативных вариантов |
| Request For Proposal (RFP) | Запрос предложения | Документ требований, который оформляется, когда организация находиться в поиске официальных предложений от поставщиков. В данном документе обычно отражаются требования для официального предложения, поддерживающие определенный процесс и используемые для заявок, к котором будет применена процедура выбора (официальная выборная методология) |
| Request For Quote (RFQ) | Неофициальный запрос | Не официальное ходатайство на предоставление информации от поставщика продукта |
| Requirement | Требование | 1. Условие или возможность, необходимое заинтересованному лицу для решения задач или достижения целей 2. Условие или возможность, которое должно быть выполнено для программы или программного компонента с целью удовлетворения условий контракта, спецификации или другого официального (навязываемого) документа. 3. Документировано представленные условия или возможности, описанные в п.1 и п.2 |
| Requirement(s) Attribute | Атрибуты требования | Метаданные, связанные с требованием и используемые в ходе разработки и управления требованиями |
| Requirement(s) Defect | Дефект требования | Ошибка в требованиях, являющаяся результатом неверных, неполных, отсутствующих или противоречивых требований |
| Requirements Allocation | Распределение требований | Процесс распределения требований по подсистемам и компонентам действующей системы |
| Requirements Discovery Session | Сессия по выявлению требований | Организованное мероприятие, на котором тщательно отобранная группа заинтересованных лиц определяет или уточняет требования под руководством квалифицированного нейтрального наблюдателя |
| Requirements Document | Документ требований | Набор требований, объединенных в документ или презентацию, для общения с заинтересованными лицами |
| Requirements Iteration | Итерация требований | Итерация, для определения подмножества требований, включенных в рамки решения. |
| Requirements Management | Управление требованиями | Деятельность, которая контролирует разработку требований, включая контроль над изменениями требований, определение характеристик требований, а также возможность отслеживания изменений требований |
| Requirements Management Plan | План управления требованиями | Описание процесса управления требованиями |
| Requirements Management Tool | Инструмент управления требованиями | Программный инструмент, который позволяет, хранить информацию по требованиям в базе данных, обеспечить фиксацию атрибутов требований и их объединение, а так же наблюдение за состоянием требований |
| Requirements Model | Модель требований | Представление требований при помощи использования текста и диаграмм. Модель требований так же может быть использована для пользовательских моделей требований или аналитических моделей. Модель требований может быть использована для текстовой спецификации требований |
| Requirements Package | Пакет требований | Пакет требований - это набор требований, объединенных вместе в документ или презентацию, для взаимодействия с заинтересованными лицами |
| Requirements Quality | Качество требований | Смотри валидацию и верификацию требований |
| Requirements Risk Mitigation Strategy | Стратегия уменьшения рисков требований | Анализ рисков, связанных с требованиями, которые оценивают риски и идентифицируют активности по избежанию или минимизации рисков |
| Requirements Signoff | Утверждение требований | Официальное утверждение набора требований спонсором или другим лицом, принимающим решение |
| Requirements Trace Matrix | Матрица трассировки требований | Матрица, используемая для отслеживания взаимосвязей между требованиями. Каждая колонка в матрице обеспечивает взаимосвязь информации по требованиям с проектными или развиваемыми (ПО) компонентами |
| Requirements Traceability | Трассировка требований | Способность идентифицировать и документировать происхождение каждого требования, в том числе его источник, его назначение, и его взаимосвязи с другими требованиями |
| Requirements Validation | Валидация требований | Процесс по подтверждению того, что установленные требования ориентированы и поддерживают цели и задачи бизнеса |
| Requirements Verification | Верификация требований | Процесс по оцениванию требования для установления того, что они корректно определены на приемлемом уровне качества. Это подтверждает то, что требования определены достаточно и структурированы таким образом, что команда разрабатывающая решение, может использовать их при разработке и развертывании решения |
| Requirements Workshop | Семинар по требованиям | Семинар по требованиям – это организованное мероприятие, на котором тщательно отобранная группа заинтересованных лиц взаимодействует для определения и/или переопределения требований, под наставничеством квалифицированного нейтрального наблюдателя |
| Retrospective | Ретроспектива | Смотри процесс извлечения уроков |
| Return on Investment | Возврат инвестиций | Мера прибыльности проекта или инвестиции |
| Risk | Риск | Неопределенное событие или состояние, которое, если оно произойдет, будет воздействовать на цели и задачи предлагаемого изменения |
| Risk Mitigation Strategy | Стратегия по снижению риска | Действия, способствующие предотвращению появления неблагоприятной ситуации и уменьшение последствий возникновения внештатной ситуации на проекте |
| Root Cause Analysis | Анализ основной причины | Анализ основной причины позволяет понять скрытые причины, неблагоприятной ситуации на проекте и события ее вызывающие |
| Scenario | Сценарий | Аналитическая модель, которая описывает ряд действий или задач, выполняемых в ответ на событие. Каждый сценарий является примером варианта использования |
| Scope | Рамки системы | Область, покрываемая конкретной деятельностью, или темой интереса |
| Scope Model | Модель рамок системы | Модель, которая определяет границы бизнес домена или решения |
| Secondary Actor | Вторичный эктор | Эктор, который вовлечен в работу, но не инициирует её |
| Sequence Diagram | Диаграмма последовательности | Тип диаграммы, которая демонстрирует объекты, принимающие участие во взаимодействии, и сообщения, которыми они обмениваются |
| Service | Сервис | Исполняемая работа от лица кого-либо |
| Software Engineer | Инженер ПО | Смотри разработчик |
| Software/Systems Requirements Specification | Спецификация программных/системных требований | Документ требований, написанный главным образом для экспертов в реализации предметной области, описывающий функциональные и нефункциональные требования |
| Solution | Решение | Решение, удовлетворяющее потребности бизнеса посредством решения проблем или позволяющее организации получить преимущественные возможности |
| Solution Requirement | Требование решения | Характеристика решения, которая удовлетворяет требованиям бизнеса и заинтересованных лиц. Может подразделяться на функциональные и нефункциональные требования |
| Solution Scope | Рамки решения | Набор возможностей решения, которые должны предоставлять систему для удовлетворения бизнес потребностей |
| Span of Control | Диапазон контроля | Диапазон контроля – это набор сотрудников, прямо или косвенно несущих ответственность перед одним менеджером |
| Sponsor | Спонсор | Заинтересованное лицо, которое разрешает или узаконивает процесс разработки продукта по условиям контракта или оплаты в рамках проекта |
| Stakeholder | Заинтересованное лицо | Человек или группа, заинтересованных в результатах, которые могут влиять с помощью инициатив или других воздействий |
| Stakeholder Analysis | Анализ заинтересованных лиц | Процесс по определению заинтересованных лиц, которые могут оказывать влияние на вносимые инициативы и оценивание их интересов и возможного участия |
| Stakeholder List, Roles, and Responsibility Designation | Список заинтересованных лиц, ролей и ответственности за назначения | Ведение списка заинтересованных лиц, находящихся под влиянием бизнес потребности или предлагаемого решения, а так же описание их участия в проекте или другой инициативе |
| Stakeholder Requirement | Требование заинтересованного лица | Требования заинтересованного лица - это заслуживающие отдельного рассмотрения утверждения заинтересованного лица или класса заинтересованных лиц. Они описывают потребности, которые должны быть предоставлены заинтересованным лицам и то, как заинтересованные лица будут взаимодействовать с решением. Требования заинтересованных лиц играют роль моста между требованиями бизнеса и различными вариантами требований решения |
| State Diagram | Диаграмма состояний | Аналитическая модель, показывающая жизненный цикл объекта (сущности) данных или класса |
| State Machine Diagram | Диаграмма автомата | Аналитическая модель, показывающая жизненный цикл объекта (сущности) данных или класса |
| State Transition Diagram | Диаграмма переходов состояний | Аналитическая модель, показывающая жизненный цикл объекта (сущности) данных или класса |
| Stated Requirements | Зафиксированные требования | Требования, выраженные заинтересованным лицом, которые не были проанализированы, верифицированы или валидированы. Зафиксированные требования часто отражают желания заинтересованных лиц более предпочтительнее, чем актуальные потребности |
| Structural Rule | Структурное правило | Структурные правила определяют, когда что-либо истинно или нет, или когда что-то попадает в определенную категорию. Они описывают категории, которые могут быть изменены с течением времени |
| Storyboard | Раскадровка | Смотри иерархию диалога или карту диалога |
| Structured Walkthrough | Структурный сквозной контроль | Структурный сквозной контроль - это организованная экспертная оценка сдаваемого продукта на наличие ошибок и упущений. Он проводиться в форме контроля качества |
| Subject Matter Expert (SME) | Эксперт в предметной области | Заинтересованное лицо с определенной экспертизой в решении или предложения потенциальных альтернатив или компонентов, аспектов проблем своей области |
| Supplier | Поставщик | Заинтересованное лицо, обеспечивающее организацию продуктом/системой или сервисом |
| Survey | Опрос | Обследование проводится на основе набора записанных вопросов к заинтересованным лицам, зафиксированных с целью сбора ответов от большой группы за относительно короткий срок |
| Swimlane | Водная дорожка | Горизонтальная или вертикальная секция модели процесса, которая демонстрирует какие активности выполняются конкретными экторами или ролями |
| SWOT Analysis | СВОТ Анализ | Аббревиатура, которая образована от сокращения терминов: Сильные стороны, Слабые стороны, Возможности, Угрозы. Эта модель используется для понимания оказывающих влияние факторов и то, как они могут влиять на инициативу |
| System | Система | Набор взаимосвязанных элементов, которые взаимодействуют для достижения цели. Системные элементы могут включать в себя аппаратное обеспечение, ПО и людей. Одна система может быть подэлементом (или подсистемой) другой системы |
| Technical Constraint(s) | Технические ограничения (ы) | Технические ограничения - это ограничения на модель решения, которые получаются при помощи, используемой при развертывании технологии |
| Technique | Техника | Техники, определяющие путь выполнения задач бизнес анализа, так же описывают определенную форму результата, который может быть получен |
| Temporal Event | Временное событие | Триггер системы, который инициируется во времени |
| Tester | Тестировщик | Заинтересованное лицо, отвечающее за оценку качества и идентификацию дефектов в программных компонентах системы |
| Throw-away Prototype | Одноразовый прототип | Прототип, используемый для быстрого выявления и уточнения требований с помощью использования простых инструментов. Иногда просто бумага и карандаш. Обычно отвергается, когда разработана последняя версия системы |
| Timebox | Фиксированный срок | Фиксированный срок для достижения желаемого результата |
| Traceability | Отслеживаемость | Смотри трассировка требований |
| Transition Requirement(s) | Транзитные требования | Классификация требований, описывающая возможности решения, которые должны быть представлены в виде перехода от конкретного состояния предприятия до желаемого в будущем состояния, но которое не необходимо единожды для того, чтобы переход был закончен |
| Unified Modeling Language (UML) | Unified Modeling Language (UML) | Нестандартизированный язык моделирования и спецификации, используемый для описания, визуализации и документации объектно-ориентированных и интенсивно разрабатываемых программ |
| Use Case | Вариант использования | Аналитическая модель, описывающая задачи, которые система будет выполнять для её экторов и цели, которые система должна достигать с помощью использования деятельности, выполняемой экторами |
| Use Case Diagram | Диаграмма варианта использования | Тип диаграммы, определяемой в UML, которая отображает всех экторов и варианты использования, включенные в систему или продукт |
| User | Пользователь | Заинтересованное лицо, сотрудник, устройство или система, которая прямо или косвенно оценивает систему |
| User Acceptance Test | Пользовательские испытания | Контрольные примеры, которые пользователи выполняют для проверки работоспособности и полноты реализации системы. Каждый тест описывает набор входных данных и ожидаемый результат выполнения теста |
| User Requirement | Требование пользователя | Смотри требование(я) заинтересованных лиц |
| User Requirements Document | Документ требований пользователя | Документ с требованиями, написанный для пользовательской аудитории, описывающий требование пользователей и влияния ожидаемых изменений на пользователей |
| User Story | Пользовательская история | Высокоуровневое, короткое описание возможностей решения, которое обеспечивает ценность для заинтересованных лиц. Пользовательская история обычно длиной в одно или два предложения, содержит минимум информации, необходимой для принятия решения разработчиком об оценке требований к рабочему процессу |
| Validated Requirements | Валидационные требования | Требования, которые продемонстрировали достижение бизнес ценностей и поддержку бизнес-целей и задач |
| Validation | Валидация | Процесс проверки продукта для подтверждения того, что он удовлетворяет своё предназначение, чтобы удостоверится в соответствии его реализации согласованным требованиям. Валидация подтверждает то, что Вы создали корректное решение |
| Variance Analysis | Анализ отклонений | Анализ рассогласованных между планируемым и актуальным состояниями, который определяет размер рассогласования и предоставляет рекомендации по корректировке и превентивных действий, в виде требований |
| Verification | Верификация | Процесс проверки того, что поставляемое или производимое решение находиться в таком состоянии, которое удовлетворяет условиям или спецификации данной, конкретной стадии. Верификация подтверждает, что Вами было создано решение корректно |
| Verified Requirements | Верификация требований | Требования, которые были показаны с целью демонстрации характеристик требований качества и таких характеристик, как полнота, совместимость, корректность, выполнимость, способность к модификации, однозначность и тестируемость |
| Vertical Prototype | Вертикальный прототип | Прототип, который раскрывает систему с точки зрения деталей интерфейса, функциональности или обоих аспектов сразу |
| Vision Statement | Видение | Краткое заявление или параграф, который описывает почему, что, и кто необходимо для производства программного обеспечения, с точки зрения бизнеса |
| Walkthrough | Прохождение | Тип экспертной оценки, в которой существующие участники, обсуждают и отыскивают ошибки в рабочем продукте. Прохождение документирования требований используется для верификации корректности требований |
| Work Breakdown Structure (WBS) | Структура разделения работ (WBS) | Ориентированная на результат декомпозиционная иерархия работ, которая должна быть выполнена для проектной команды с целью выполнения проектных задач и создания нужного конечного продукта. Она организуется и выполняется для общих рамок проекта |
| Work Product | Рабочий продукт | Документ или совокупность заметок (шаблонов) или диаграмм, используемых бизнес-аналитиком в течении процесса разработки требований |
