Глоссарий

Подсистема – это отдельный технический компонент программного обеспечения в рамках общей архитектуры системы.

Модуль — это артефакт, группирующий фичи с целью лучшей систематизации и структурирования.

Модули группируют фичи по функциональным или техническим аспектам.

Каталог модулей позволяет получить верхнеуровневую картину по разработке и тестированию фич без необходимости анализа отдельных фич.

Фича — основной артефакт для описания низкоуровневых требований к определенной части ПО, трекинга реализации и тестирования.

Мы долго искали подходящий термин в русском языке, но краткого слово, описывающего артефакт, который может описывать одновременно функциональные и нефункциональные требования мы не нашли и решили оставить "Фичи".

Фича описывает функциональные и нефункциональные требования для определенной функциональности проекта. В некоторых случаях фича может использоваться для описания исключительно нефункциональных требований, относящихся к отдельной области проекта (модулю) или проекту в целом.

Фича является центральным артефактом в Reqode, к которым привязываются другие артефакты требований, разработки и тестирования, такие как спецификации, задачи, тест-кейсы и программные юниты.

Бизнес-требование — артефакт, описывающий верхнеуровневые требования к определенной части ПО.

Верхнеуровневые требования могут включать как бизнес-требования (описание бизнес-процесса, цели и т.д.), так и пользовательские требования (варианты использования, пользовательские истории) или любой тип требований, который Вы настроите в проекте.

Слово "бизнес" в названии указывает на то, что в отличие от Модулей и Фич, эти артефакты используются для верхнеуровневых требований, которые идут со стороны бизнеса (заказчика) и/или пользователей. Эти требования не учитывают детали реализации, но могут ссылаться на фичи, с помощью которых они реализуются.

Таким образом, бизнес-требования позволяют определить ожидания бизнеса и пользователей от проекта, и набор фич, с помощью которых реализуются эти ожидания.

Бизнес-требования – это опциональный артефакт. Для небольших проектов, или проектов где заинтересованные стороны со стороны разработки и бизнеса тесно переплетены, этот тип артефактом может быть не актуален.

Модель данных — каталог сущностей, которыми оперирует программное обеспчение.

В зависимости от настроек, в дополнение к текстовому описанию могут использоваться следующие инструменты описания сущностей:

• Атрибуты и связи;
• Списки значений (например, для определения возможных состояний, типов и т.д.)

Пользовательские интерфейсы описывают экраны, формы и состояния значимые для анализа требований.

Программные интерфейсы (API) описывают точки взаимодействия между системами для реализации требований.

Каталог, позволяющий создавать кастомные типы артефактов для систематизации и трассировки элементов ПО (например, события, уведомления, конфигурационные переменные и другие).

Ревизия — сохранённое состояние артефакта, включающее описание, атрибуты и связи артефакта.

Бейзлайн фиксирует состояние всех требований проекта. В проекте может быть только один активный бейзлайн. Новый бейзлайн создаётся при архивации текущего. Используется для отслеживания изменений и версий требований.

Ветка — параллельная версия артефактов. Используется для разработки новых версий без внесения изменений в активный бейзлайн.

Актор — класс пользователей, взаимодействующих с системой. Применяется для классификации фич и бизнес-требований.

Задача — артефакт, связанный с фичами и бизнес-требованиями, предназначенный для описания конкретных работ.

Эпик — артефакт, объединяющий несколько связанных задач.

Эпик может рассматриваться как мини-проект по реализации изменений и доработок.

К эпику могут быть привязаны конкретные ревизии артефактов требований, которые должны быть реализованы в рамках эпика. Это позволяет использовать эпик как запрос на изменение.

Веха — инструмент для управления временными интервалами, в рамках которых выполняются работы по разработке и тестированию ПО.

В зависимости от используемой методологии, вехи могут использоваться для определения итераций, спринтов или релизов.

Тест-кейс — артефакт, описывающий способ проверки фичи.

Тестран — проверка набора тест-кейсов в определенном окружении.

Тест-план — шаблон для создания тест-рана.

Проверка — результат прохождения тест-кейса в рамках тест-рана.

Окружение — настройки и конфигурация для проведения тестирования.