Связи трассируемости помогают следить за развитием требования в обоих направлениях — от первоисточника к реализации и наоборот (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% усилий. Возможно, вам нужно только отслеживать тестирование системы до функциональных требований или вариантов использования. Решите, какие связи уместны в вашем проекте, и вы в значительной степени поспособствуете успешной разработке и эффективному обслуживанию. Не просите членов команды тратить много времени на фиксирование информации, если у вас нет четкого представления о использовании этой информации.