Матрица трассируемости требований

Наиболее типичный способ представления связей между требованиями и другими элементами системами — матрица трассируемости требований, которую также называют матрицей отслеживания требований или таблицей трассируемости (requirements traceability matrix) (Sommerville и Sawyer, 1997). В табл. 20-показана часть такой матрицы для Chemical Tracking System. Когда я раньше создавал такие матрицы, я делал копию базовой версии спецификации требований и удалял все, кроме идентификаторов функциональных требований. Затем я создавал таблицу, отформатированную так же, как табл. 20-1, и заполнял только столбец Функциональное требование. Далее мы постепенно заполняли пустые ячейки в матрице по мере разработки проекта.

Таблица 20-1. Один из типов матрицы трассируемости требований

В табл. 20-1 показано, как каждое функциональное требование связано с определенным вариантом использования (в направлении назад) и с одним или более элементами проектирования, кода и тестирования (в направлении вперед). Элементы дизайна могут быть объектами в таких моделях анализа, как диаграммы потока данных, таблицы в реляционной модели данных или классах объектов. Ссылки кода могут быть методами класса, хранимыми процедурами, именами файлов исходного кода, а также процедурами или функциями в исходном файле. Вы вправе добавить дополнительные столбцы для расширения ссылок на другие рабочие продукты, например на документацию справочной системы. Добавление деталей трассируемости - дополнительная работа, но так вы получаете точные расположения связанных элементов ПО, что экономит массу времени при анализе влияния и обслуживании.

Заполняйте информацию по мере выполнения работы, а не по мере планирования. То есть вводите «catalog.sort()» в столбец Модуль кода первой строки в табл. 20-1 только когда код в этой функции написан, прошел тестирование элементов и уже интегрирован с базовой версией исходного кода продукта. Таким образом, читающий матрицу будет знать, что заполненный ячейки матрицы для отслеживания требований указывают на работу, которая уже выполнена. Обратите внимание, что перечисление вариантов тестирования для каждого требования не указывает на то, что ПО протестировано. Это просто означает, что определенные тесты были написаны для проверки требований в соответствующее время. Трассирование состояния тестов— это отдельная проблема.

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

Рис. 20-3. Пример цепи трассируемости для требований, касающихся безопасности приложения

Связи трассируемости могут определить отношения «один к одному», «один ко многим» или «многие ко многим» между элементами системы. Формат в табл. 20-1 предусматривает это, позволяя вводить несколько позиций в каждой ячейке таблицы. Ниже приведены примеры возможных связей.

· «Один к одному»: один элемент проектирования реализуется в одном модуле кода.

· «Один ко многим»: одно функциональное требование проверяется множеством вариантов тестирования.

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

Другой способ представить информацию трассируемости — с помощью набора матриц, определяющих связи между парами элементов системы, например:

· один тип требования с другим требованием этого же типа;

· один тип требования с требованием другого типа;

· один тип требования с вариантами тестирования.

Вы можете использовать эти матрицы для определения различных взаимоотношений, возможными между парами требований, например «указывает/указан», «зависит от», «является родительским для» и «ограничивает/ограничен» (Sommerville и Sawyer, 1997).

В табл. 20-2 показана двусторонняя матрица трассируемости. Большинство ячеек матрицы не заполнены. Каждая ячейка на пересечении двух связанных компонентов помечена для указания соединения. Вы можете использовать различные символы в ячейках, чтобы явно определить «трассируется до» и «трассируется от» или другие взаимоотношения. В табл. 20-2 стрелка указывает, что данное функциональное; требование отслеживается от определенного варианта использования. Эти матрицы более поддаются автоматизации средствами поддержки, чем те, что показаны в табл. 20-1.

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

	Вариант использования (ВИ)
Функциональное требование (ФТ)	ВИ-1	ВИ-2	ВИ-3	ВИ-4
ФТ-1
ФТ-2
ФТ-3
ФТ-4
ФТ-5.
ФТ-6

Связи трассируемости должны быть определены любым лицом, имеющим доступ к соответствующей информации. В табл. 20-3 определены некоторые стандартные источники информации о связях между различными типами исходных и целевых объектов. Определите роли и лиц, которые будут поддерживать каждый тип информации трассируемости для вашего проекта. Будьте готовы к тому, что занятые люди, которых аналитик или менеджер проекта попросит предоставить эти данные, будут отнекиваться. Этим специалистам стоит объяснить, что такое трассирование требований, чем оно ценно и почему именно этих специалистов просят внести вклад в процесс. Подчеркните, что увеличение затрат на фиксирование информации трассируемости во время выполнения невелики; в основном это вопрос привычки и дисциплины.

Таблица 20-3. Вероятные источники информации о связи трассируемости