CRUD-матрица ~ CRUD matrix — таблица, связывающая действия системы с элементами данных, чтобы показать, где каждый элемент создается (Created), читается (Read), обновляется (Updated) и удаляется (Deleted). Planguage — основанный на ключевых словах язык, предложенный Томом Гилбом (Tom Gilb) и позволяющий создать точную и количественно оцениваемую спецификацию требований.
Swimlane-диаграмма ~ diagram — модель анализа, показывающая последовательные шаги потока бизнес-процессов предлагаемой программной системы. Процесс разбивается на визуальные компоненты, называемые дорожками, которые показывают системы или действующие лица, выполняющие эти шаги.
TBD — сокращение от To Be Determined. Служит для отметки неясностей или пропусков, которые надо заполнить, в информации требований.
UML (Unified Modeling Language) — набор стандартной нотации для создания различных визуальных моделей систем, особенно в объектно-ориентированном программировании.
Альтернативное направление ~ alternative flow — направление, учитывающее вариант использования, которое ведет к успеху (достижение цели действующего объекта), но которое подразумевает отклонение от нормального направления в специфике задач или при взаимодействии объекта с системой.
Анализ первопричин ~ root cause analysis — действия, которые предпринимаются для поиска основных причин, вызывающих наблюдаемые проблемы.
Анализ расхождение ~ gap analysis — сравнение текущего состояния и альтернативного или возможного состояния системы, процесса или другого аспекта бизнес-ситуации для выявления значительных расхождений между ними.
Анализ требований ~ requirements analysis — процесс классификации информации, касающейся требований, по различным категориям, оценка требований для определения желаемого качества, представление требований в различных формах, выделение детальных требований из требований более высокого уровня, обсуждение приоритетов требований и т. д.
Архитектура ~ architecture — структура системы, включающая все ПО, оборудование и людей, из которых она состоит, интерфейсы и взаимосвязи между этими компонентами и поведение компонентов, видимое другим компонентам.
Атрибут качества ~ quality attribute — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта. Примеры атрибутов качества: удобство и простота использования, легкость перемещения, легкость в эксплуатации, целостность, надежность, эффективность и устойчивость к сбоям. В требованиях описаны рамки атрибутов качества, до которых продукт демонстрирует желаемые характеристики.
Атрибут требования ~ requirement attribute — описательная информация о требованиях, которая дополняет описание желаемой функциональности продукта. К ней относятся источники данных, логические обоснования, приоритеты, ответственные лица, номера версий и выпусков.
Бизнес-аналитик ~ business analyst — роль члена команды по разработке требований, основная обязанность которой — работа с заинтересованными лицами над выявлением, анализом, определением, утверждением и управлением требованиями в проекте. Эта роль также может называться аналитик требований, системный аналитик, разработчик требований и просто аналитик.
Бизнес-правило ~ business rule — политика, предписание, стандарт, правило или вычислительная формула, определяющая или ограничивающая некоторые стороны бизнес-процессов.
Бизнес-требования ~ business requirement — объем информации, который в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. Бизнес-требования включают бизнес-возможности, бизнес-цели, метрики успеха, концепция и границы и ограничения.
Бизнес-цель ~ business objective — финансовая или нефинансовая выгода, которую организация ожидает получить в результате реализации проекта или другой инициативы.
Блок-схема ~ flowchart — модель, которая показывает этапы процесса и точки принятия решений в логике процесса или программы. Аналогична диаграмме взаимодействия.
Большие данные ~ big data — обычно описывают массив данных, отличительные особенности которых — большой объем (много данных), высокая скорость (данные быстро поступают в организацию) и/или высокая сложность (данные очень разнородны). Управление большими данными предусматривает обнаружение, сбор, хранение и обработку больших объемов данных быстро и эффективно.
Бумажный прототип ~ paper prototype — непрограммная модель пользовательского интерфейса ПО с недорогими, несложными в исполнении эскизами экрана.
Вариант использования ~ use case — описание набора логически связанных возможных взаимодействий действующего лица и системы, которые дают результат, ценный для действующего лица. Может включать много сценариев.
Взаимосвязь «расширить» ~ extend relationship — конструкция, в которой альтернативное направление ответвляется от нормального направления в отдельный «расширенный» вариант использования.
Владелец продукта ~ product owner — роль, обычно в команде проекта гибкой разработки, представляющая клиента и отвечающая за определение концепции продукта, предоставление границ и ограничений проекта, определение приоритетов запаса продукта и принятие решений по продукту.
Внешняя сущность ~ external entity — объект в контекстной диаграмме или диаграмма потока данных, представляющая класс пользователей, действующее лицо, программную или аппаратную систему и являющийся внешним к описываемой системе, но так или иначе взаимодействует с ней. Также называется оконечным устройством.
Водопадный жизненный цикл проекта ~ waterfall development life cycle — модель процесса разработки ПО, в которой различные действия с требованиями, дизайном, кодированием, тестированием и развертыванием выполняются последовательно, с небольшим наложением или итерациями.
Встроенная система ~ embedded system — система, содержащая аппаратные компоненты, управляемые ПО, работающем на выделенном компьютере, являющемся частью более крупного продукта.
Выходное условие ~ postcondition — условие, описывающее состояние системы после успешного завершения варианта использования.
Выявление требований ~ requirements elicitation — процесс определения требований из различных источников посредством интервью, семинаров, анализа задач, рабочих потоков и документов и других механизмов.
Гибкая разработка ~ agile development — методы разработки ПО, характеризующиеся постоянным взаимодействием между разработчиками и клиентами. К методам гибкой разработки относятся экстремальное программирование (Extreme Programming), Scrum, разработка, управляемая функциональностью (Feature Driven Development), бережливая разработка программного обеспечения (Lean Software Development) и Kanban.
Граница проекта ~ scope — часть концепции конечного продукта, реализуемой в ходе текущего проекта. Определяет границу между тем, что входит и что не входит в проект, в котором создается определенный выпуск или итерация.
Действующее лицо ~ actor — лицо, играющее конкретную роль, программная система или аппаратное устройство, которое взаимодействует с системой для достижения полезных целей. Также называется ролью пользователя.
Дерево решений ~ decision tree — модель анализа, которая графически показывает действия системы в ответ на все комбинации набора факторов, которые влияют на поведение части системы.
Дерево функций ~ feature tree — модель анализа, отображающая функции, запланированные для продукта, в виде иерархического дерева и отображающая до двух уровней подчиненных функций в каждой функции.
Дефект требования ~ requirement issue — проблема, открытый вопрос или решение относительно требования. Это могут быть элементы, помеченные как «TBD» (to be determined — необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п.
Диаграмма (или машина) состояний ~ state machine diagram — модель анализа, показывающая представления различных состояний, которые могут принимать объекты системы на протяжении своего жизненного цикла в ответ на то или иное событие или отображающая возможные состояния системы в целом. Похожа на диаграмму перехода состояний.
Диаграмма «сущность–связь» ~ entity-relationship diagram — модель анализа, которая показывает логические взаимосвязи между парами объектов. Используется для моделирования данных.
Диаграмма вариантов использования ~ use case diagram — модель анализа с указанием действующих лиц, которые могут взаимодействовать с системой для выполнения задач, и различные варианты использования, в которых может участвовать действующее лицо.
Диаграмма взаимодействия ~ activity diagram — аналитическая модель, которая позволяет динамически представить систему, посредством изображения потока процессов от одной функции к другой. Схожа с блок-схемой.
Диаграмма классов ~ class diagram — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи.
Диаграмма перехода состояний ~ state-transition diagram — модель анализа, показывающая возможные состояния системы или объектов в ней, разрешенные переходы между ними и условия и/или события, инициирующие каждый переход. Аналогична диаграмме или машине состояний.
Диаграмма потока данных ~ data flow diagram — модель анализа, описывающая процесс, хранилища данных, внешние сущности и потоки, характеризующие поведение данных, проходящих через бизнес-процессы или программные системы.
Документ о концепции и границах ~ vision and scope document — документ, в котором определены бизнес-требования к новой системе, в том числе положения о концепции продукта и описания границы проекта.
Документы процесса ~ process assets — документы, такие как шаблоны, формы, списки, политики, процедуры, описание процессов и примеры рабочих продуктов, которые собраны для эффективного применения в организации с целью улучшить приемы разработки ПО.
Допущение ~ assumption — положение, которое считается верным в отсутствие доказательств или точных знаний.
Зависимость ~ dependency — зависимость проекта от внешних факторов, событий или групп, находящихся вне зоны контроля.
Заинтересованное лицо ~ stakeholder — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.
Исключение ~ exception — условие, которое может помешать успешному завершению варианта использования. Если некоторые возвратные механизмы не работают, то выходные условия варианта использования не достигаются и желаемая цель не достигается.
Итерация ~ iteration — непрерывный период разработки, обычно от одного до четырех недель, во время которого команда разработки реализует определенный набор функциональности, выбранной из резерва продукта, или базовой версии требований к продукту.
Каркас ~ wireframe — разновидность одноразового прототипа, который используется для предварительного дизайна веб-страниц.
Карта диалоговых окон ~ dialog map — модель анализа, описывающая архитектуру пользовательского интерфейса, показывая видимые диалоговые элементы и навигацию между ними.
Карта экосистемы ~ ecosystem map — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи. В отличие от контекстных диаграмм, карта экосистемы показывает системы, имеющие отношения друг с другом, даже если между ними нет интерфейса.
Класс пользователей ~ user class — группа пользователей системы, имеющих схожие требования к системе. Члены пользовательского класса функционируют как действующие лица при взаимодействии с системой.
Класс ~ class — описание набора объектов, имеющих общие свойства и поведение, которые стандартным образом соотносятся с элементами реального мира (людьми, местами или вещами) в бизнесе или определенной предметной области.
Клиент ~ customer — человек или организация, получающая от продукта прямую или косвенную выгоду. Клиенты это заинтересованные в проекте лица, запрашивающие, оплачивающие, выбирающие, определяющие, использующие и получающие результаты работы программного продукта.
Количество элементов ~ cardinality — количество элементов данных объектов или данных, которые связаны с элементами других объектов или данных. Например, «один к одному», «один ко многим» или «многие ко многим».
Контекстная диаграмма ~ context diagram — аналитическая модель, которая описывает абстрактную систему высокого уровня. Контекстная диаграмма определяет внешние для системы объекты, которые взаимодействуют с ней, но не отображает ничего из внутренней структуры или поведения системы.
Концепция ~ vision — утверждение, описывающее стратегический принцип конечной цели и формы новой системы.
Критерий приемлемости ~ acceptance criteria — условия, которым продукт должен удовлетворять, чтобы его приняли пользователи, клиенты или другие заинтересованные лица.
Матрица отслеживания связей требований ~ requirements traceability matrix — таблица, отображающая логические связи между функциональными требованиями и другими системными артефактами, в том числе функциональными требованиями, пользовательскими требованиями, бизнес-требованиями, элементами архитектуры и дизайна, модулями кода, тестами и бизнес-правилами.
Модель ~ mock-up — частичная или возможная реализация пользовательского интерфейса для систем ПО. Применяется для оценки легкости и простоты использования, а также завершенности и корректности требований. Может представлять собой программу или прототип на бумаге. Также называется горизонтальным прототипом.
Модель бизнес-целей ~ business objectives model — визуальное представление иерархии бизнес-задач и бизнес-целей.
Нефункциональное требование ~ nonfunctional requirement — описание присущих свойств или характеристик, которые система ПО должна демонстрировать, или ограничения, которые она должна соблюдать.
Нормальное направление ~ normal course — последовательность действий, заданная по умолчанию в варианте использования, которая ведет к удовлетворению выходных условий этого варианта использования или достижению целей пользователей. Другие названия: нормальное направления развития, базовый поток, нормальная последовательность, основной успешный сценарий и счастливый путь (happy path).
Ограничение ~ constraint — налагается на доступные разработчику возможности дизайна или конструирования продукта. Другие типы ограничений могут ограничить возможности, доступные для менеджеров проектов. Бизнес-правила часто накладывают ограничения на бизнес-операции, а значит, на программные системы.
Одноразовый прототип ~ throwaway prototype — прототип, который создается с расчетом, что после его использования для уточнения и утверждения требований и вариантов дизайна он будет выброшен.
Оперативный профиль ~ operational profile — комплект сценариев, который представляет ожидаемые случаи применения ПО.
Организатор мероприятия ~ facilitator — лицо, ответственное за планирование и работу группы, например работу семинара по выявлению требований.
Основная версия требований ~ requirements baseline — зафиксированный в определенный момент времени, согласованный, просмотренный и одобренный набор требований, обычно определяющих определенный выпуск продукта или итерацию разработки. Служит основой для дальнейшей разработки.
Отношение включения ~ include relationship — конструкция, в которой несколько шагов, повторяющихся во многих вариантах использования, выделяются в отдельный вложенный вариант использования, который вызывается по мере необходимости.
Отслеживание ~ tracing — процесс определения логических связей между одним элементом системы (вариантом использования, функциональными требованиями, бизнес-правилами, компонентами дизайна, фрагментами кода, тестами и т. д.) и другим.
Панель мониторинга ~ dashboard — изображение на экране или в печатном документе с множественными текстовыми и/или графическими представлениями данных, предоставляющее консолидированное многомерное представление происходящего в организации или процессе.
Пилотная версия ~ pilot — контролируемое выполнение нового решения (такого как процесс, инструмент, программная система или учебный курс) для оценки его работы в реальных условиях и готовности к развертыванию.
Повторное использование требований ~ requirements reuse — использование существующих требований во многих системах, отличающихся одинаковой функциональностью.
Пользователь ~ user — клиент, который взаимодействует с системой непосредственно или косвенно (например, пользуется результатами работы системы, хотя не генерирует эти результаты). Также называется конечным пользователем.
Пользовательская история ~ user story — способ выражения пользовательских требований в проектах гибкой разработки в форме одного или двух предложений, формулирующих потребность пользователя или описывающих единицу необходимой функциональности, а также говорящих о пользе, какую эта функциональность приносит пользователю.
Пользовательское требование ~ user requirement — цель и задача, которую пользователи должны иметь возможность выполнять с системой, или положения об ожиданиях пользователей о качестве системы. Пользовательские требования обычно представляются в виде вариантов использования, пользовательских историй и сценариев.
Поток процесса ~ process flow — последовательные шаги бизнес-процесса или операций предложенной программной системы. Обычно предоставляется с применением диаграммы взаимодействия, блок-схемы, swimlane-диаграммы или другой нотации моделирования.
Правило решения ~ decision rule — согласованный способ выработки единого решения в группе людей.
Предварительные условия ~ precondition — условия, которые должны быть удовлетворены, или состояние, в котором система должна пребывать, чтобы мог начаться вариант использования.
Приемочный тест ~ acceptance test — тест для проверки ожидаемых вариантов использования с целью определения приемлемости ПО. Используется в проектах гибкой разработки для представления подробностей пользовательских историй и определения правильности их реализации.
Приоритизация, определение приоритетов, расстановка приоритетов ~ prioritization — акт определения того, какие требования программного продукта наиболее важны для достижения бизнес-успеха и в каком порядке должны реализовываться требования.
Проверка ~ verification — процесс оценки рабочего продукта, позволяющий определить, удовлетворяет ли он спецификации, на основе которой создан. Обычно формулируется в виде вопроса: «Правильно ли мы создаем продукт?»
Продукт ~ product — конечный результат разработки, выполняемой в рамках проекта. В этой книге используются также термины-синонимы «приложение», «система» и «решение».
Проект с чистого листа ~ green-field project — проект, в котором разрабатывается новое ПО или новая система.
Прототип ~ prototype — частичная, предварительная или возможная реализация программы. Применяется для исследования и утверждения требований, а также для разработки приемов. Прототипы бывают эволюционные, одноразовые, бумажные, горизонтальные и вертикальные.
Процедура ~ procedure — пошаговое описание направления действия для выполнения и завершения конкретной работы.
Процесс ~ process — последовательность действий, выполняемых для достижения конкретной цели. Описание процесса представляет собой документированное определение этих действий.
Процесс создания требований, процесс построения требований ~ requirements engineering — область, которая охватывает все стороны жизненного цикла проекта, связанные с необходимыми возможностями и атрибутами продукта. Состоит из разработки требований и управления требованиями. Считается подобластью процессов построения системы и ПО.
Рабочий продукт ~ work product — любой промежуточный или окончательный результат, созданный в проекте разработки ПО.
Разработка требований ~ requirements development — процесс определения границ проекта, классов и представителей пользователей, выявления, анализа, спецификации и утверждения требований. Результатом этого процесса считается основная версия требований, в которой указано, что за продукт должен быть построен.
Расползание границ проекта ~ scope creep — условия, при которых границы проекта неконтролируемо расширяются на протяжении всего процесса.
Распределение требований, назначение требований ~ requirements allocation — процесс распределения системных требований по различным архитектурным и компонентным подсистемам.
Резерв продукта ~ product backlog — в проекте гибкой разработки, распределенные по приоритетам список еще не реализованных задач проекта. Резерв может содержать пользовательские истории, бизнес-процессы, запросы на изменение и разработку инфраструктуры. Рабочие элементы из резерва назначаются на будущие итерации на основе их приоритетов.
Ретроспектива ~ retrospective — рецензирование, в котором участники анализируют действия и результаты проекта с целью определения путей повышения успешности последующих проектов.
Рецензирование ~ peer review — действия, предпринимаемые одной или несколькими лицами (не авторами продукта), для исследования продукта с целью обнаружить возможные дефекты и улучшить возможности.
Решение ~ solution — все компоненты, которые должны быть созданы в процессе реализации проекта для достижения бизнес-целей, определенных организацией, в том числе ПО, оборудование, бизнес-процессы, руководство пользователя и обучение.
Риск ~ risk — условие, которое может привести к потере или иным образом поставить под угрозу успех проекта.
Серийные продукты, коммерческие готовые продукты ~ COTS (commercial offtheshelf) product — готовый пакет ПО, приобретаемый у поставщика. Применяется как готовое решение или интегрируется, настраивается и расширяется в соответствии с потребностями клиента для удовлетворения нужд последнего.
Система ~ system — продукт, содержащий много программных или аппаратных подсистем. В общеупотребимом смысле используется в этой книге в отношении приложения, продукта и решения для обозначения любого содержащего ПО результата, создаваемого командой.
Система бизнес-аналитики ~ business analytics system — программная система, служащая для преобразования больших и сложных наборов данных в осмысленную информацию, на основе которой можно принимать решения.
Система реального времени ~ real-time system — аппаратная или программная система, которая должна реагировать в четко определенное время на заданные события.
Системное требование ~ system requirement — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
Словарь данных ~ data dictionary — набор определений элементов данных, структуры и атрибутов, относящихся к определенной предметной области.
Событие ~ event — инициирующее или стимулирующее событие, которое происходит в системной среде, например поведение функции или изменение состояния.
Совет по управлению изменениями ~ change control board — группа сотрудников, отвечающая за решение о принятии или отклонении предлагаемых изменений в требованиях к ПО.
Спецификация требований к продукту ~ software requirements specification — набор функциональных и нефункциональных требований к продукту ПО.
Сторонник продукта ~ product champion — назначенный представитель отдельного класса пользователей, который предоставляет пользовательские требования представляемых им групп пользователей.
Сущность ~ entity — элемент области бизнеса, данные о котором собираются и сохраняются.
Схема требования ~ requirement pattern — систематический подход к определению определенного типа требований.
Сценарий ~ scenario — описание взаимодействия пользователя и системы с целью достижения некоторой цели. Пример работы с системой. Один из путей развития варианта использования.
Таблица «событие–реакция» ~ event-response table — перечень внешних или зависящих от времени событий, которые могут влиять на систему, и описание того, как система будет отвечать на каждое из них.
Таблица решения ~ decision table — модель анализа в виде матрицы, где показаны все комбинации значений для наборов факторов, которые влияют на поведение части системы, и определены ожидаемые действия системы в ответ на каждую комбинацию.
Таблица состояний ~ state table — модель анализа, показывающая в виде матрицы состояния, в которых может находиться система или ее объекты, а также какие возможны переходы между состояниями.
Требование ~ requirement — документ, где указаны потребности или цели пользователей либо условия и возможности, которыми должен обладать продукт, чтобы удовлетворить такие возможности или цели. Свойство, которым должен обладать продукт, чтобы представлять ценность для заинтересованного лица.
Требования для интерфейса внешнего устройства ~ external interface requirement — описание интерфейса между системой ПО и пользователем, другой системой ПО или оборудованием.
Требования-«бантики», украшательство ~ gold plating — не являющаяся необходимой или избыточно сложная функциональность, запланированная и разработанная для продукта, иногда без одобрения клиента.
Управление требованиями ~ requirements management — работа с определенным набором требований к продукту, начиная от процесса разработки продукта и заканчивая поддержкой действующего продукта. Управление подразумевает отслеживание состояния продукта, управление изменениями требований и версиями спецификаций требований, а также отслеживание требований до других требований и элементов системы.
Утверждение ~ validation — процесс оценки рабочего продукта, позволяющий определить, действительно ли он удовлетворяет потребности клиента. Обычно формулируется в виде вопроса: «Создаем ли мы правильный продукт?»
Функциональная точка ~ function point — мера размера ПО, основанная на числе и сложности внутренних логических файлов, файлов интерфейса внешнего устройства, вводимых извне данных, результатов и запросов.
Функциональное требование ~ functional requirement — описание поведения системы в определенных условиях.
Функция ~ feature — одна или несколько логически связанных возможностей системы, которые представляют ценность для пользователя и описаны рядом функциональных требований
Цикл разработки ПО ~ software development life cycle — последовательность действий, в которой ПО определяется, конструируется, строится и проверяется.
Шаблон ~ template — образец, который используется в качестве руководства при создании всеобъемлющей документации или других элементов.
Эволюционный прототип ~ evolutionary prototype — полностью функциональный прототип, построенный как скелет или некая стадия конечного продукта, которые постепенно будут «обрастать мясом» по мере прояснения требований.
Экспериментальный образец ~ proof of concept — прототип, реализующий часть содержащей программную часть системы и охватывающий много уровней архитектуры. Применяется для оценки технической осуществимости и производительности. То же самое, что вертикальный прототип.
Эксперт предметной области ~ subject matter expert — лицо, имеющее обширный опыт и знания в предметной области и считающееся полномочным источником информации о предметной области.
Экспертиза ~ inspection — тип рецензирования, когда члены специально созданной команды в определенном и строгом порядке исследуют рабочий продукт на предмет выявления дефектов.
Эпика ~ epic — пользовательская история в проекте гибкой разработки, которая слишком большая, чтобы ее можно было реализовать в одной итерации разработки. Эпика разбивается на более мелкие истории, каждая из которых может быть реализована в одной итерации.
Литература
Карл Вигерс и Джой Битти — Разработка требований к программному обеспечению. Издание третье, дополненное. 2013 год.