tbd steam что значит
Что это за TBD рейтинг такой?
12 Apr 2014 в 18:20
12 Apr 2014 в 18:20 #1
там у чувака в колонке «рейтинг» стоит «TBD». Что это значит? Сам не сталкивался, но на скринах вижу не в первый раз.
12 Apr 2014 в 18:22 #2
12 Apr 2014 в 18:22 #3
Рейтинг еще неизвестен, очевидно же.
12 Apr 2014 в 18:23 #4
12 Apr 2014 в 18:24 #5
12 Apr 2014 в 18:24 #6
такой рейтинг только у Дондо. Значит тебе повезло сыграть с Дондо
12 Apr 2014 в 18:25 #7
а никого не смутило то что он рак?
и играет за инвока 10-11
12 Apr 2014 в 18:27 #8
У них у всех отрицательные счета т.е это был какой-то камбек с голым троном
TBD — что это такое? Магистральная разработка программ для ПК
TBD — что это значит в программировании
Основная идея TBD состоит в том, чтобы не использовать объединение отдельных ветвей функции с основной ветвью при раздельной разработке, а применять деление таких функций на небольшие части, которые сразу помещаются в «ствол» разработки и разрабатываются всеми программистами. Если простыми словами, то команда разработчиков программирует без четкого применения деления на отдельные ветви разработки, а целиком работает над конкретной частью.
Магистральная разработка приносит очень важное преимущество перед другими моделями — в ней практически отсутствуют конфликты при слиянии отдельных ветвей общей разработки.
Преимущества TBD
Помимо основного преимущества, описанного выше, TBD-модель — это еще ряд достоинств, которые нужно отметить:
Быстрое развертывание. TBD совместно с конвейером CI/CD дает возможность разворачивать функциональный код непосредственно в самом сердце производства. Это облегчает интеграцию рабочих частей и развертывание самой разработки. Плюс ко всему это дает хорошую возможность в случае обнаружения ошибок «откатить» разработку до рабочего состояния, так как «рабочие состояния» фиксируются.
Высокое качество кода. TBD — это то, что обеспечивает устойчивый и качественный код, начиная с самой базы, а вероятность ошибок сильно снижается. Также эта модель дает возможность использовать «принцип 4-х глаз», когда минимум 2 отдельных программиста просматривают код перед его отправкой в «ствол» всей разработки. Для этого используется парная разработка, когда программисты работают по двое, а не п оо диночке, помогая и проверяя друг друга. При этом ответственность за качество их части кода лежит на них двоих.
Командная работа. Парная разработка улучшает командный дух. Плюс это дает возможность более слабым разработчикам работать с более сильными, тем самым перенимать опыт и становиться лучше. А также общее дело поднимает градус ответственности и коммуникации между членами команды.
Потенциальные недостатки TBD
Помимо достоинств этой модели разработки, у нее есть собственные потенциальные недостатки. Почему потенциальные? Потому что во многих TBD-командах они отсутствуют, но в принципе их наличие не исключено.
TBD — это то, что обладает следующими потенциальными недостатками:
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Tbd steam что значит
Смотреть что такое «TBD» в других словарях:
TBD — (to be determined) yet to be determined … English contemporary dictionary
TBD — Die Abkürzung TBD steht für: Tumorbasisdokumentation in der onkologischen Epidemiologie Douglas TBD, einen amerikanischen Flugzeugtyp To be defined/determined, engl. für noch festzulegen, und ähnliche Ausdrücke, siehe Wiktionary Siehe auch:… … Deutsch Wikipedia
TBD — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Sigles d’une seule lettre Sigles de deux lettres > Sigles de trois lettres Sigles de quatre lettres … Wikipédia en Français
TBD — to be determined. * * * abbr US to be determined used to indicate that the time or place of something has not yet been decided and will be announced at a later time The game has been postponed until next week, time TBD … Useful english dictionary
TBD — to be determined … Military dictionary
TBD — abbreviation to be determined … New Collegiate Dictionary
TBD — to be determined. * * * … Universalium
TBD — To Be Determined (Governmental » Military) To Be Determined (Academic & Science » Ocean Science) ** To Be Defined (Governmental » NASA) * To Be Discussed (Computing » Telecom) * To Be Decided (Governmental » Military) * To Be Decided (Computing » … Abbreviations dictionary
TBD — total body density; Toxicology Data Base … Medical dictionary
TBD — • To Be Determined • To Be Defined NASA • To Be Developed NASA … Acronyms
Словарь терминов (глоссарий) по разработке требований (Вигерс, 2013)
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 год.