Трассируемость требований

Borland Caliber - одно из специализированных средств управления требованиями, поддерживающее трассируемость

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

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

Назначение

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

В этом смысле трассируемость является важным свойством, поддерживающим определение системы как компромисса между конкурирующими интересами заинтересованных лиц, так как именно конкуренция интересов является одним из основных источников изменений требований.Метавселенная ВДНХ 2.7 т

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

Инструменты трассируемости требований используются и для выявления артефактов системы, не связанных с другими артефактами, что позволяет выявить недостающие «звенья» разработки. Например, возможно выявление вариантов использования, с которыми не ассоциировано сценариев тестирования.

Разновидности

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

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

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

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

Инструментальная поддержка

Трассируемость требований в проекте может поддерживаться и без использования специализированных инструментальных средств, с помощью соглашений об именовании и соблюдения аналитиками формализованных процедур управления требованиями. При этом может использоваться функционал ПО общего назначения, например, механизмы управления структурой документа и составными документами, а также перекрестных ссылок и гиперссылок текстовых редакторов, функционал сортировки и фильтрации данных в электронных таблицах, механизмы настольных СУБД.

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

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

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

К специализированным средствам управления требованиями, поддерживающим трассируемость, относятся, в частности, средства Borland Caliber, IBM Rational RequisitePro, (IBM) Telelogic DOORS, Sparx Enterprise Architect, 3SL Cradle,

В рамках проекта Eclipse инициировано создание Open Source Requirements Framework, предназначенного для создания модели управления требованиями, а также инструментов на её базе.

Источники

• Open Source Requirements Framework project. ORMF Requirements model 2.0
• Wikipedia Contributors. Requirements Traceability