Связи трассируемости помогают следить за развитием требования в обоих направлениях — от первоисточника к реализации и наоборот (Gotel и Finkelstein, 1994). В главе 1 Трассируемость определяется, как одна из характеристик отличной спецификации требований. Чтобы реализовать Трассируемость, каждое требование должно быть уникально и последовательно идентифицировано, чтобы вы могли ссылаться на него однозначно в ходе работы над проектом. Пишите требования маленькими фрагментами, а не большими абзацами, в которых содержится множество отдельных функциональных требований — это приводит к разбросу элементов проектирования и кода.
Рис. 20-1. Четыре типа трассируемости требований
На рис. 20-1 показаны четыре типа связей трассируемости (Jarke, 1998). Потребности клиента отслеживаются в направлении к требованиям (forward to requirements), чтобы вы смогли определить, которые требования будут затронуты, если в течение или после разработки потребности изменятся. Это также дает уверенность, что в спецификации требований указаны все потребности клиента. И, наоборот, вы можете проследить в направлении от требований (backward from requirements) к потребностям клиента, чтобы определить происхождение каждого требования к ПО. Если вы представите потребности клиента в форме вариантов использования, то верхняя половина рис. 20-1 будет показывать трассирование между вариантами использования и функциональными требованиями.
Взглянув на нижнюю часть рис. 20-1, ясно, что по мере приближения к поставке, вы можете отслеживать в направлении от требований, определив связи между отдельными требованиями и элементами продукта. Это тип связи гарантирует, что каждое требование удовлетворено, поскольку вы знаете, какой компонент соответствует каждому требованию. Четвертый тип связи контролирует отдельные элементы продукта в направлении к требованиям для того, чтобы вы знали причину созданию каждого элемента. В большинство приложений включен код, не относящийся напрямую к требованиям пользователей, но вы должны знать, почему написана каждая строка кода.
Предположим, тестировщик обнаружит незапланированную функциональность при отсутствии соответствующего требования. Этот фрагмент кода может свидетельствовать, что разработчик реализовал официальное требование, которое аналитик теперь может добавить к спецификации. Или же это может быть код-сирота, украшающий фрагмент, который не относится к продукту. Связи трассируемости помогут вам отсортировать подобные ситуации и получить более полное представление о том, как именно фрагменты вашей системы составляют одно целое. И наоборот, варианты тестирования, которые созданы на основе отдельных требований и которые можно проследить до этих требований, также представляют собой механизм выявления нереализованных требований, поскольку ожидаемой функциональности не будет.
Связи трассируемости помогают отслеживать родительские требования, взаимосвязи и зависимости между отдельными требованиями, Эта информация показывает влияние изменения, если отдельное требование удаляется или модифицируется. Если вы сопоставили отдельные требования с задачами в структуре проекта, то эти задачи будут затронуты при изменении или удалении требования.
Рис. 20-2. Возможные связи трассирования требований
На рис. 20-2 показано множество типов прямых взаимосвязей трассируемости, возможных в проекте. Вам не нужно определять и управлять всеми этими типами связей трассируемости. Во многих проектах удается получить 80% преимуществ трассируемости, вложив приблизительно 20% усилий. Возможно, вам нужно только отслеживать тестирование системы до функциональных требований или вариантов использования. Решите, какие связи уместны в вашем проекте, и вы в значительной степени поспособствуете успешной разработке и эффективному обслуживанию. Не просите членов команды тратить много времени на фиксирование информации, если у вас нет четкого представления о использовании этой информации.