Блог

Типы связей между требованиями: как мировые и отечественные стандарты управляют трассируемостью

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

Мировые и российские стандарты, от SysML до ГОСТов, предлагают свои подходы к этим связям – с разной терминологией, но схожими принципами. Мы разобрали семь ведущих методологий и выделили, какие именно типовые связи между требованиями они используют, зачем это нужно и как помогает бизнесу и командам.

Содержание

  1. Зачем нужны связи между требованиями
  2. Методология SysML: инженерный подход к связям
  3. BABOK: взгляд бизнес-аналитика
  4. ISO/IEC/IEEE 29148: международный стандарт трассируемости
  5. Agile и Scrum: связи в гибкой разработке
  6. SAFe: иерархия требований на уровне предприятия
  7. ГОСТ 34: советская структура в современной ИТ-реальности
  8. ГОСТ 19: традиции прослеживаемости в ПО
  9. Общие тенденции: к чему сходятся все подходы
  10. Практика: как применять связи в корпоративных ИТ-системах

1. Зачем нужны связи между требованиями

В больших ИТ-проектах бизнес-цели трансформируются в десятки и сотни требований, реализаций и проверок. Без связи между ними невозможно понять:

  • откуда возникло требование;
  • реализовано ли оно в коде;
  • покрыто ли тестами;
  • на что повлияет его изменение.

Связи между требованиями формируют трассируемость – цепочку от потребности до реализации. Она позволяет:

  • выявлять пробелы;
  • анализировать риски;
  • планировать изменения;
  • проходить аудиты и сертификацию.

Методологии предлагают разные типы этих связей – но суть одна: создать живую структуру, где требования «цепляются» за реализацию и тесты, образуя контролируемую систему.

2. Методология SysML: инженерный подход к связям

SysML (Systems Modeling Language) – это мощный язык системного моделирования, широко используемый в инженерии для построения целостных моделей сложных систем. Одним из его ключевых преимуществ является способность формализованно описывать связи между требованиями и другими элементами модели.

В SysML предусмотрены следующие типы связей (стереотипов):

  • Derive – указывает, что одно требование выведено из другого, более высокого уровня. Такая связь позволяет выстраивать иерархию требований: от бизнес-целей к системным требованиям и далее к компонентным спецификациям. Например, требование «Система должна быть безопасной» может порождать Derive-связь к более конкретному требованию: «Аутентификация должна включать одноразовый код».
  • Refine – отражает детализацию требования через модели поведения, сценарии использования или диаграммы активности. Это помогает связать абстрактное требование с конкретной реализацией и упростить его интерпретацию. Например, требование «Удобство пользователя» можно Refine-связью связать с user flow, описывающим пошаговое взаимодействие.
  • Satisfy – устанавливает связь между требованием и элементом архитектуры, который это требование реализует. Это своего рода “мост” от требований к системе к её структуре. Если модуль X реализует требование Y, связь Satisfy указывает: модуль удовлетворяет требование.
  • Verify – показывает, каким тестом или средством верификации проверяется выполнение конкретного требования. Такие связи особенно важны в критичных системах, где необходимо продемонстрировать, что каждое требование протестировано.
  • Trace – универсальная связь без строго определённой семантики, применяется в случаях, когда ни один из специфичных типов не подходит. Используется для информативного связывания элементов модели – с возможностью уточнения в комментарии.
  • Copy – означает, что требование было скопировано из другого для повторного использования. Такая связь позволяет управлять повторяющимися требованиями в разных контекстах, сохраняя единообразие и возможность синхронизации изменений.

SysML позволяет выстраивать деревья требований, связывать их с архитектурой и тестами, строить матрицы трассируемости. Это даёт полное покрытие: от цели до кода и обратно.

3. BABOK: взгляд бизнес-аналитика

BABOK (Business Analysis Body of Knowledge) – это международный свод знаний по бизнес-анализу, разработанный IIBA. Он предлагает системный, но более «гуманитарный» подход к управлению требованиями, ориентированный на потребности бизнеса и заинтересованных сторон. BABOK делает акцент на понимании взаимосвязей между требованиями, их источниками и реализацией.

Методология определяет следующие типы связей:

  • Derive – указывает, что одно требование вытекает из другого, более высокого уровня. Это отражает естественную декомпозицию: от бизнес-целей и проблем – к конкретным решениям. Например, потребность «Сократить время обработки заказов» может порождать derived-требования на автоматизацию проверки данных и интеграцию с логистикой.
  • Depends on – означает зависимость одного требования от другого. Выделяют два подтипа:
    • по необходимости (necessity) – без A требование B теряет смысл;
    • по усилиям (effort) – наличие A упрощает реализацию B. Это помогает выявлять скрытые риски и логические связи. Например, функция «просмотра видео» зависит от функции «загрузки видео» — без неё первая невозможна.
  • Satisfy – устанавливает, какой компонент системы реализует требование. Это создаёт прозрачность: аналитик может показать, как именно решение отвечает исходным потребностям. Например, требование «пользователь должен получать уведомления» удовлетворяется компонентом «Push-уведомлений».
  • Validate – описывает, каким способом будет проверено выполнение требования: тест, сценарий использования, критерий приёмки. Это критично для формализации завершения работы над функциональностью. Например, требование «Пользователь может изменить пароль» валидируется тест-кейсом, проверяющим шаги на экране смены пароля.

BABOK подчеркивает прослеживаемость от потребности до решения и обратно – особенно при управлении изменениями и дефектами. Используется матрица трассируемости (RTM) – инструмент для анализа влияния и контроля реализации.

4. ISO/IEC/IEEE 29148: международный стандарт трассируемости

ISO/IEC/IEEE 29148:2018 — это международный стандарт, определяющий подходы к управлению требованиями на протяжении всего жизненного цикла системы. Он входит в семейство стандартов по системной и программной инженерии и служит ориентиром для построения структурированной, управляемой и проверяемой системы требований.

Стандарт выделяет несколько ключевых типов отношений:

  • Parent–Child – отражает иерархические связи между требованиями. Верхнеуровневые (родительские) требования, такие как цели заказчика или бизнес-потребности, декомпозируются на более детализированные (дочерние) требования: системные, подсистемные и далее – до требований к программным компонентам. Это обеспечивает согласованность и полноту: каждое низкоуровневое требование должно «служить» какому-то высокоуровневому.
  • Allocation – показывает распределение требований между компонентами системы. Требование должно быть «аллоцировано» конкретному модулю или подсистеме, которая отвечает за его реализацию. Это позволяет командам понимать зоны ответственности и контролировать, что все требования учтены при проектировании архитектуры.
  • Origin – указывает источник требования: откуда оно появилось. Это может быть потребность пользователя, регламент, бизнес-цель или результат анализа. Указание происхождения помогает обосновать каждое требование и избегать лишнего функционала.
  • Traceability – общий принцип, означающий, что каждое требование должно быть связано с другими элементами жизненного цикла: проектными решениями, кодом, тестами, документами. Такая связь обязательна как для целей контроля, так и для аудита.

Стандарт требует двунаправленной трассируемости:

  • Вперёд (forward traceability) – от требования к его реализации, архитектурному решению, коду, тест-кейсам и результатам валидации. Это нужно, чтобы убедиться, что каждое требование реализовано и проверено.
  • Назад (backward traceability) – от любого элемента проекта (например, найденного дефекта или модуля кода) к исходному требованию, которое он реализует. Это особенно важно при анализе последствий изменений и при сертификации.

5. Agile и Scrum: связи в гибкой разработке

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

Тем не менее, в рамках Scrum и других фреймворков Agile активно используются следующие типы структурных и логических связей:

  • Epic → Story – иерархическая связь между крупной задачей (эпиком) и конкретными пользовательскими историями. Эпик представляет собой обобщённое требование или бизнес-цель, которая декомпозируется на множество историй. Например, эпик «Управление профилем пользователя» может включать user stories: «Как пользователь, я могу загрузить фото профиля» и «… видеть информацию о других пользователях».
  • Story → Task – детализация истории на более мелкие, технически ориентированные задачи. Эти задачи – единицы работы для команды, и их выполнение означает реализацию всей user story. Такая связь близка к Refine/Implement: требование (story) уточняется конкретными действиями (tasks), которые реализуют ожидаемую функциональность.
  • Acceptance Criteria – критерии приёмки, определяющие, при каких условиях история считается завершённой. Они служат неформальным аналогом Validate-связей, поскольку именно по ним проводится проверка правильности реализации. В тестировании acceptance criteria часто превращаются в автоматизированные тест-кейсы, особенно при использовании BDD (Behavior-Driven Development).
  • Dependencies – зависимости между историями. Хотя Scrum поощряет независимость user stories, на практике часто возникают ситуации, когда реализация одной истории невозможна без завершения другой. Например, история «Пользователь может просматривать видео» зависит от истории «Пользователь может загрузить видео». В инструментах типа Jira такие зависимости фиксируются явно (Blocked by, Depends on), позволяя учитывать их при планировании спринтов.

Особенности управления связями в Scrum

Классический Scrum не требует ведения матрицы трассируемости, поскольку команды предполагаются автономными и тесно коммуницирующими. Однако в корпоративных или регулируемых проектах такая документация становится необходимой.

Для обеспечения прослеживаемости в Agile-командах обычно используют:

  • ссылки из user stories на требования заказчика или регламенты;
  • иерархическую структуру backlog’а (Epic → Story → Task);
  • документированные acceptance criteria, играющие роль валидирующих условий;
  • интеграцию с системами тестирования, где тест-кейсы ссылаются на связанные истории.

Применение в практике

В компаниях, использующих Agile на уровне бизнеса, часто строится следующая цепочка:

Бизнес-цель → Epic → User Stories → Tasks → Acceptance Criteria → Тесты.

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

Кроме того, популярные инструменты (Jira, Azure DevOps, Rally) поддерживают связи между уровнями и позволяют визуализировать их в виде досок, отчётов или деревьев. Это приближает Agile к формализованным стандартам управления требованиями, сохраняя при этом гибкость и наглядность.

Хотя Scrum не требует матриц трассируемости, в корпоративной среде они часто используются – особенно в Jira, Confluence и других ALM-инструментах.

6. SAFe: иерархия требований на уровне предприятия

SAFe (Scaled Agile Framework) – это методология масштабирования Agile-подходов на уровень крупных организаций. В отличие от классического Scrum, SAFe предлагает четкую многоуровневую структуру требований, которая охватывает все уровни управления: от стратегических инициатив до задач конкретной команды разработки.

Основная иерархия требований в SAFe выглядит следующим образом:

  • Epics – самые крупные единицы работы на уровне портфеля. Эпики отражают бизнес-инициативы или технологические преобразования, требующие значительных ресурсов и времени. Пример: «Цифровизация процесса выдачи кредитов».
  • Capabilities – крупные функции на уровне решений (solution level), применяются в больших системах. Это промежуточный уровень между эпиком и фичами. Пример: «Поддержка видеоидентификации клиентов».
  • Features – функциональные возможности, которые приносят ценность пользователю и могут быть реализованы в течение одного программного инкремента (PI). Например: «Загрузка документов через мобильное приложение».
  • Stories – пользовательские истории, реализуемые за один спринт. Они детализируют фичи и составляют рабочий backlog команды.

Такой подход формирует сквозную трассируемость: от высокоуровневых целей до конкретных задач, выполняемых разработчиками. Все элементы иерархии логически связаны, и каждая Story должна быть привязана к Feature, а та – к Epic (через Capability или напрямую).

Non-Functional Requirements (NFRs)

Особенностью SAFe является явное включение нефункциональных требований (Non-Functional Requirements). Они могут применяться к любому уровню: как к отдельным историям, так и ко всей системе в целом. Примеры NFR: требования к производительности, безопасности, масштабируемости.

NFR в SAFe фиксируются отдельно, но трассируются через те же уровни, что и функциональные требования. Например, требование к отказоустойчивости может относиться ко всем фичам, реализуемым в определённой системе.

Выравнивание и прослеживаемость

Одной из ключевых целей SAFe является выравнивание команд с бизнес-целями организации. Это достигается за счёт трассируемости:

  • Каждая Story «знает», к какой фиче она относится;
  • Каждая Feature входит в структуру эпика;
  • Эпики связаны с целями портфеля или стратегическими темами.

Для управления этими связями в SAFe задействуются роли: Epic Owners, Product Managers, Product Owners, которые отвечают за связность требований на каждом уровне. Используются канбан-системы, доски, backlog-и и визуализации зависимостей (например, Program Board).

В инструментах (например, Jira Align, TargetProcess, Azure DevOps) реализованы сквозные связи между уровнями, которые можно отслеживать и визуализировать для анализа влияния изменений и планирования релизов.

SAFe предлагает одну из самых формализованных и масштабируемых систем управления требованиями среди Agile-подходов. Благодаря иерархии Epics → Capabilities → Features → Stories и учёту NFR, достигается сквозная прослеживаемость, прозрачность и управляемость даже в очень крупных и распределённых командах.

7. ГОСТ 34: советская структура в современной ИТ-реальности

ГГОСТ 34.602-89 – это советский (и до сих пор применяемый в России) государственный стандарт, регламентирующий структуру технического задания (ТЗ) на создание автоматизированной системы (АС). Несмотря на возраст и отсутствие современной терминологии, он содержит принципы управления требованиями и трассируемости, схожие с подходами ISO и BABOK.

Ключевые особенности ГОСТ 34:

  • Иерархия требований – требования делятся по уровням: общесистемные, функциональные, к видам обеспечения, по подсистемам. Это фактически отражает связь Derive: от общего – к частному. Например, требование «Обеспечить информационную безопасность» может быть конкретизировано в требование «Реализовать двухфакторную аутентификацию» в разделе безопасности.
  • Связь требований с компонентами системы – реализуется через структуру документации. В разделе «Требования к составу и параметрам технических средств» или «Требования к программному обеспечению» указываются, какие подсистемы реализуют конкретные функции. Это аналог Satisfy: решение связано с требованием через текстовое соответствие.
  • Связь требований с тестами – происходит через документ «Программа и методика испытаний», который создаётся на основе требований ТЗ. Там прямо указывается, какие пункты ТЗ проверяются каким испытанием. Это позволяет сформировать структуру, аналогичную связям Validate/Verify.
  • Текстовые ссылки и нумерация – в ТЗ требования имеют уникальные номера (например, 5.2.3), которые затем используются в проектной и испытательной документации. Это обеспечивает идентификацию и позволяет строить простейшую матрицу трассируемости вручную.

Как работает трассируемость в ГОСТ 34

Хотя сам стандарт не вводит формализованные типы связей, на практике прослеживаемость строится документально. Например:

  1. В ТЗ указано требование 5.3.1: «Система должна защищать аккаунт пользователя при компрометации пароля».
  2. В техническом проекте (документ по ГОСТ) описано решение: «Внедрена двухфакторная аутентификация».
  3. В Программе испытаний есть пункт: «Проверка защиты аккаунта при вводе известного пароля».
  4. В таблице соответствия указано, что данный тест проверяет выполнение требования 5.3.1.

ГОСТ 34 обеспечивает трассируемость через строгую структуру документации. Хотя типы связей не формализованы, они де-факто реализуются в логике: иерархия требований, соответствие проектным решениям и проверка через испытания. Это делает ГОСТ полезным даже в современных ИТ-проектах – особенно там, где важны прозрачность и контроль

Современное применение

Сегодня ГОСТ 34 по-прежнему используется в проектах по гособоронзаказу, для госучреждений, в банках и на предприятиях с повышенными требованиями к формализации. Часто он применяется в сочетании с современными методами (Agile, SysML, ALM-системы). Например, в Jira в user story могут быть ссылки на номера требований ТЗ по ГОСТ.

Также появился обновлённый ГОСТ 34.602-2020, в котором усиливаются положения о прослеживаемости, терминология приближается к международным стандартам, а требования к структуре остаются узнаваемыми.

 

8. ГОСТ 19: традиции прослеживаемости в ПО

ГОСТ 19.201-78 и соГОСТ 19.201-78 – один из ключевых стандартов Единой системы программной документации (ЕСПД), применяемый для описания и оформления требований к программному обеспечению. В отличие от ГОСТ 34, ориентированного на автоматизированные системы в целом, ГОСТ 19 фокусируется на программной части проекта.

Хотя в стандарте нет терминов вроде Satisfy или Validate, на практике в документации, оформленной по ГОСТ 19, реализуется трассируемость требований по тем же принципам, что и в международных подходах.

Основные особенности ГОСТ 19:

  • Деление требований на группы – структура Технического задания (ТЗ) по ГОСТ 19 включает разделы, такие как: функциональные требования, требования к надежности, интерфейсам, условиям эксплуатации и др. Это позволяет систематизировать требования и формировать их иерархическую структуру (аналог Derive).
  • Связь требований с реализацией – осуществляется через пояснительные записки (ГОСТ 19.402), где в разделе «Описание функций программы» указывается, какие функции реализованы в коде. Там же часто даются ссылки на соответствующие пункты ТЗ. Это эквивалент связи Satisfy: программный модуль реализует указанное требование.
  • Связь с тестами – формализована в документе «Программа и методика испытаний» (ПМИ) по ГОСТ 19.301-79. В ПМИ приводятся испытания, направленные на проверку выполнения конкретных требований. В таблицах явно указывается: какой тест соответствует какому пункту ТЗ. Это обеспечивает трассировку Validate/Verify.
  • Таблицы соответствия требований и тестов – часто включаются в ПМИ или итоговую отчетность по приёмке. Такие таблицы фактически являются матрицей трассируемости (RTM): по строкам – требования, по столбцам – тесты, с отметками о проверке и результатах.

 

9. Общие тенденции: к чему сходятся все подходы

Независимо от времени создания, отрасли или методологической школы — будь то инженерный SysML, бизнес-ориентированный BABOK, гибкий Agile, формализованные ГОСТы или международные стандарты вроде ISO 29148 — все подходы к управлению требованиями сходятся в одном: связи между требованиями необходимы. Причём не просто «для порядка», а как ключевой механизм прозрачного и успешного управления проектами.

Вот основные тенденции, которые можно выделить:
Иерархия требований (Derive, Parent–Child) – основа структуры

Почти все методологии используют декомпозицию требований по уровням. Это может быть:

  • от бизнес-целей к пользовательским историям;
  • от требований заказчика – к системным и программным;
  • от общих эпиков – к фичам и задачам.

Такая структура задаёт логику: каждое детализированное требование должно «служить» более высокому, а каждое высокоуровневое – быть расшифровано до уровня реализуемого. Это основа для построения дерева требований, что критично при планировании и валидации.

Указание зависимостей (Depends on) – для согласованности

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

  • планировать реализацию в нужной последовательности;
  • избежать конфликтов;
  • видеть, как изменения в одном требовании «цепляют» другие.

Примеры: зависимость user story от другой истории в Jira («Blocked by»), связка требований «по необходимости» в BABOK или неявные зависимости в ГОСТ-документации.

Связь с реализацией и тестами (Satisfy, Verify, Validate) – для полноты

Независимо от методологии, важнейшая цель – убедиться, что каждое требование:

  • реализовано в системе (связь с архитектурой, кодом, компонентом),
  • и проверено (через тест, критерий приемки, сценарий).

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

Двунаправленная трассируемость – видеть и влияние, и обоснование

Лучшая практика – трассировать требования в обе стороны:

  • Вперёд (Forward Traceability): от требования к реализации и тестам. Позволяет проверить полноту – всё ли реализовано.
  • Назад (Backward Traceability): от кода, теста или бага – к исходному требованию. Необходимо при анализе дефектов и управлении изменениями.

Эта двунаправленность формирует замкнутый контур управления требованиями, защищающий проект от потерь, дублирования и ошибок.

Ограниченный набор типов – для управляемости

Хотя можно придумать десятки разновидностей связей, на практике большинство организаций ограничиваются 5–7 ключевыми типами. Это делает систему трассируемости:

  • понятной для всех участников;
  • устойчивой к разрастанию и хаосу;
  • удобной для автоматизации и визуализации.

Классический набор:
Derive / Refine,
Depends on,
Satisfy / Implement,
Verify / Validate,
иногда – Copy / Trace / Constraint.

Международные стандарты, ГОСТы, agile-фреймворки и инженерные методологии – все они формируют единое поле знаний, которое сводится к простому выводу:

Требования — это не изолированные пункты в ТЗ, а живые элементы системы, связанные между собой, с реализацией и с проверкой.

Когда эти связи выстроены, проект становится управляемым, прозрачным и устойчивым к изменениям. А когда нет – возникают потери, дублирование, технический долг и провалы на приёмке.

10. Практика: как применять связи в корпоративных ИТ-системах

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

  • откуда пришло каждое требование,
  • кем и как оно реализовано,
  • проверено ли оно и чем.

Именно для этого в реальных проектах активно внедряется трассируемость требований. Причём не только как формальность, а как инструмент управления рисками, бюджетом и качеством.

Что это даёт бизнесу и команде

Аудит и соответствие: особенно важно в регулируемых отраслях – финансы, медицина, авиация, госзаказ.

Прозрачность: видно, какие бизнес-цели реализованы, что ещё в работе, а что потерялось или дублируется.

Контроль: любое изменение можно отследить до кода и обратно – какие части проекта затронуты, какие риски.

Уверенность: на каждое требование есть реализация и тест. Нет «мертвых» требований или кода «в никуда».

 

Что в итоге?

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

Они:

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

Проект с прослеживаемыми требованиями — это проект, который живёт не по наитию, а по логике и контролю. А в современном корпоративном ИТ это уже не роскошь, а необходимость.