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

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

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

Трассируемость (traceability) – это возможность проследить связи одного элемента проекта с другим. Цель установления трассируемости требований состоит в том, чтобы помочь:

• Понимать источник требования.

• Управлять изменениями требования.

• Оценить последствия для проекта, вызванные изменением требования.

Элементы, между которыми устанавливаются отношения трассировки

1. Потребности заинтересованных лиц (бизнес-требовния) к функциям (рис. 2).

2. Функции продукта к программным требованиям и прецедентам.

3. Программных требований и прецедентов к планам тестов, тестовым спецификациям, результатам тестов.

3. UML-диаграмм к документам и требованиям.

4. Программных требований и прецедентов к компонентам реализации, такими как функции, модули, объекты, реализации прецедентов.

5. Компонентов реализации к планам/спецификациям/результатами тестов.

Рис. 1 . Отношение трассировки между элементами проекта

Установка между двумя элементами проекта отношения трассировки показывает их зависимость, изменение одного из них повлияет на другой. Отношения трассировки представляются в виде матрицы трассировки, где по горизонтали и по вертикали располагаются элементы проекта (разнотипные или однотипные), а пометка на их пересечении показывает трассируемость. Для этого можно использовать автоматические средства управления требованиями Rational Requisite Pro, Doors Telelogic. При отсутствии автоматических средств можно использовать электронные таблицы и базы данных.

Рис. 2. Матрица отношений трассировки.

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

Возможные ошибки

1. Пропущенные отношения.

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

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

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

2. "Лишние" отношения.

При проверке столбцов матрицы трассировки могут обнаружиться столбцы, не связанные ни с одной строкой, т.е. для функции не существует связанного с ним бизнес-требования. Иными словами, по-видимому, функция является лишним. Как и ранее, следует проверить отношения трассировки.